You are viewing the version of this documentation from Perl 5.39.7. This is a development version of Perl.

CONTENTS

NAME

Test2::API::Context - Object to represent a testing context.

DESCRIPTION

The context object is the primary interface for authors of testing tools written with Test2. 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 Test2::Hub instance.

SYNOPSIS

In general you will not be creating contexts directly. To obtain a context you should always use context() which is exported by the Test2::API 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;
}

CRITICAL DETAILS

you MUST always use the context() sub from Test2::API

Creating your own context via Test2::API::Context->new() will almost never produce a desirable result. Use context() which is exported by Test2::API.

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.

You MUST always release the context when done with it

Releasing the context tells the system you are done with it. This gives it a chance to run any necessary callbacks or cleanup tasks. If you forget to release the context it will try to detect the problem and warn you about it.

You MUST NOT pass context objects around

When you obtain a context object it is made specifically for your tool and any tools nested within. If you pass a context around you run the risk of polluting other tools with incorrect context information.

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.

You MUST NOT store or cache a context for later

As long as a context exists for a given hub, all tools that try to get a context will get the existing instance. If you try to store the context you will pollute other tools with incorrect context information.

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.

You SHOULD obtain your context as soon as possible in a given tool

You never know what tools you call from within your own tool will need a context. Obtaining the context early ensures that nested tools can find the context you want them to find.

METHODS

$ctx->done_testing;

Note that testing is finished. If no plan has been set this will generate a Plan event.

$clone = $ctx->snapshot()

This will return a shallow clone of the context. The shallow clone is safe to store for later.

$ctx->release()

This will release the context. This runs cleanup tasks, and several important hooks. It will also restore $!, $?, 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.

$ctx->throw($message)

This will throw an exception reporting to the file and line number of the context. This will also release the context for you.

$ctx->alert($message)

This will issue a warning from the file and line number of the context.

$stack = $ctx->stack()

This will return the Test2::API::Stack instance the context used to find the current hub.

$hub = $ctx->hub()

This will return the Test2::Hub instance the context recognizes as the current one to which all events should be sent.

$dbg = $ctx->trace()

This will return the Test2::EventFacet::Trace instance used by the context.

$ctx->do_in_context(\&code, @args);

Sometimes you have a context that is not current, and you want things to use it as the current one. In these cases you can call $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.

$ctx->restore_error_vars()

This will set $!, $?, 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.

$! = $ctx->errno()

The (numeric) value of $! when the context was created.

$? = $ctx->child_error()

The value of $? when the context was created.

$@ = $ctx->eval_error()

The value of $@ when the context was created.

EVENT PRODUCTION METHODS

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.

$event = $ctx->pass()