| Test2::API::Context - Object to represent a testing context. |
Test2::API::Context - Object to represent a testing context.
The context object is the primary interface for authors of testing tools written with the Test2 manpage. The context object represents the context in which a test takes place (File and Line Number), and provides a quick way to generate events from that context. The context object also takes care of sending events to the correct the Test2::Hub manpage instance.
In general you will not be creating contexts directly. To obtain a context you
should always use context() which is exported by the the Test2::API manpage module.
use Test2::API qw/context/;
sub my_ok {
my ($bool, $name) = @_;
my $ctx = context();
if ($bool) {
$ctx->pass($name);
}
else {
$ctx->fail($name);
}
$ctx->release; # You MUST do this!
return $bool;
}
Context objects make it easy to wrap other tools that also use context. Once you grab a context, any tool you call before releasing your context will inherit it:
sub wrapper {
my ($bool, $name) = @_;
my $ctx = context();
$ctx->diag("wrapping my_ok");
my $out = my_ok($bool, $name);
$ctx->release; # You MUST do this!
return $out;
}
context() sub from Test2::APITest2::API::Context->new() will almost never
produce a desirable result. Use context() which is exported by the Test2::API manpage.
There are a handful of cases where a tool author may want to create a new
context by hand, which is why the new method exists. Unless you really know
what you are doing you should avoid this.
If you are certain that you want a different tool to use the same context you
may pass it a snapshot. $ctx->snapshot will give you a shallow clone of
the context that is safe to pass around or store.
If you are certain that you want to save the context for later, you can use a
snapshot. $ctx->snapshot will give you a shallow clone of the context
that is safe to pass around or store.
context() has some mechanisms to protect you if you do cause a context to
persist beyond the scope in which it was obtained. In practice you should not
rely on these protections, and they are fairly noisy with warnings.
snapshot()release()$!, $?, and $@ to what they were when the
context was created.
Note: If a context is acquired more than once an internal refcount is kept.
release() decrements the ref count, none of the other actions of
release() will occur unless the refcount hits 0. This means only the last
call to release() will reset $?, $!, $@,and run the cleanup tasks.
throw($message)alert($message)stack()hub()trace()$ctx->do_in_context(sub { ... }). The codeblock will be run, and
anything inside of it that looks for a context will find the one on which the
method was called.
This DOES NOT affect context on other hubs, only the hub used by the context will be affected.
my $ctx = ...;
$ctx->do_in_context(sub {
my $ctx = context(); # returns the $ctx the sub is called on
});
Note: The context will actually be cloned, the clone will be used instead of the original. This allows the thread id, process id, and error variables to be correct without modifying the original context.
restore_error_vars()$!, $?, and $@ to what they were when the context was
created. There is no localization or anything done here, calling this method
will actually set these vars.
errno()$! when the context was created.
child_error()$? when the context was created.
eval_error()$@ when the context was created.
Which one do I use?
The pass* and fail* are optimal if they meet your situation, using one of
them will always be the most optimal. That said they are optimal by eliminating
many features.
Method such as ok, and note are shortcuts for generating common 1-task
events based on the old API, however they are forward compatible, and easy to
use. If these meet your needs then go ahead and use them, but please check back
often for alternatives that may be added.
If you want to generate new style events, events that do many things at once,
then you want the *ev2* methods. These let you directly specify which facets
you wish to use.
pass()pass($name)$name for the assertion.
The the Test2::Event::Pass manpage is a specially crafted and optimized event, using this will help the performance of passing tests.
pass_and_release()pass_and_release($name)pass() and release(). You can use this if you do
not plan to do anything with the context after sending the event. This helps
write more clear and compact code.
sub shorthand {
my ($bool, $name) = @_;
my $ctx = context();
return $ctx->pass_and_release($name) if $bool;
... Handle a failure ...
}
sub longform {
my ($bool, $name) = @_;
my $ctx = context();
if ($bool) {
$ctx->pass($name);
$ctx->release;
return 1;
}
... Handle a failure ...
}
fail()fail($name)$name and @diagnostics messages.
Diagnostics messages can be simple strings, data structures, or instances of the Test2::EventFacet::Info::Table manpage (which are converted inline into the the Test2::EventFacet::Info manpage structure).
fail_and_release()fail_and_release($name)fail() and release(). This can be used to write
clearer and shorter code.
sub shorthand {
my ($bool, $name) = @_;
my $ctx = context();
return $ctx->fail_and_release($name) unless $bool;
... Handle a success ...
}
sub longform {
my ($bool, $name) = @_;
my $ctx = context();
unless ($bool) {
$ctx->pass($name);
$ctx->release;
return 1;
}
... Handle a success ...
}
pass() and fail()
which produce the Test2::Event::Pass manpage and the Test2::Event::Fail manpage events. These
newer event types are faster and less crufty.
This will create an the Test2::Event::Ok manpage object for you. If $bool is false
then an the Test2::Event::Diag manpage event will be sent as well with details about the
failure. If you do not want automatic diagnostics you should use the
send_event() method directly.
The third argument \@on_fail) is an optional set of diagnostics to be sent in
the event of a test failure. Unlike with fail() these diagnostics must be
plain strings, data structures are not supported.
note($message)diag($message)plan($max)bail($reason)send_ev2(%facets)This example sends a single assertion, a note (comment for stdout in Test::Builder talk) and sets the plan to 1.
my $event = $ctx->send_event(
plan => {count => 1},
assert => {pass => 1, details => "A passing assert"},
info => [{tag => 'NOTE', details => "This is a note"}],
);
build_e2(%facets)send_ev2(), except it builds and returns the event
without sending it.
send_ev2() and release().
sub shorthand {
my $ctx = context();
return $ctx->send_ev2_and_release(assert => {pass => 1, details => 'foo'});
}
sub longform {
my $ctx = context();
my $event = $ctx->send_ev2(assert => {pass => 1, details => 'foo'});
$ctx->release;
return $event;
}
This lets you build and send an event of any type. The $Type argument should
be the event package name with Test2::Event:: left off, or a fully
qualified package name prefixed with a '+'. The event is returned after it is
sent.
my $event = $ctx->send_event('Ok', ...);
or
my $event = $ctx->send_event('+Test2::Event::Ok', ...);
This is the same as send_event(), except it builds and returns the event
without sending it.
This is a combination of send_event() and release().
sub shorthand {
my $ctx = context();
return $ctx->send_event_and_release(Pass => { name => 'foo' });
}
sub longform {
my $ctx = context();
my $event = $ctx->send_event(Pass => { name => 'foo' });
$ctx->release;
return $event;
}
There are 2 types of hooks, init hooks, and release hooks. As the names suggest, these hooks are triggered when contexts are created or released.
These are called whenever a context is initialized. That means when a new instance is created. These hooks are NOT called every time something requests a context, just when a new one is created.
This is how you add a global init callback. Global callbacks happen for every context for any hub or stack.
Test2::API::test2_add_callback_context_init(sub {
my $ctx = shift;
...
});
This is how you add an init callback for all contexts created for a given hub. These callbacks will not run for other hubs.
$hub->add_context_init(sub {
my $ctx = shift;
...
});
This is how you specify an init hook that will only run if your call to
context() generates a new context. The callback will be ignored if
context() is returning an existing context.
my $ctx = context(on_init => sub {
my $ctx = shift;
...
});
These are called whenever a context is released. That means when the last
reference to the instance is about to be destroyed. These hooks are NOT
called every time $ctx->release is called.
This is how you add a global release callback. Global callbacks happen for every context for any hub or stack.
Test2::API::test2_add_callback_context_release(sub {
my $ctx = shift;
...
});
This is how you add a release callback for all contexts created for a given hub. These callbacks will not run for other hubs.
$hub->add_context_release(sub {
my $ctx = shift;
...
});
This is how you add release callbacks directly to a context. The callback will ALWAYS be added to the context that gets returned, it does not matter if a new one is generated, or if an existing one is returned.
my $ctx = context(on_release => sub {
my $ctx = shift;
...
});
This object consumes the Test2::Util::ExternalMeta manpage which provides a consistent way for you to attach meta-data to instances of this class. This is useful for tools, plugins, and other extensions.
The source code repository for Test2 can be found at http://github.com/Test-More/test-more/.
Copyright 2019 Chad Granum <exodist@cpan.org>.
This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
See http://dev.perl.org/licenses/
| Test2::API::Context - Object to represent a testing context. |