perldoc > Test2::API

๐Ÿ“› NAME

Test2::API - Primary interface for writing Test2 based testing tools.

โš ๏ธ INTERNALS NOTE: The internals of this package are subject to change at any time! The public methods provided will not change in backwards-incompatible ways (once there is a stable release), but the underlying implementation details might. Do not break encapsulation here!

Currently the implementation is to create a single instance of the Test2::API::Instance Object. All class methods defer to the single instance. There is no public access to the singleton, and that is intentional. The class methods provided by this package provide the only functionality publicly exposed.

This is done primarily to avoid the problems Test::Builder had by exposing its singleton. We do not want anyone to replace this singleton, rebless it, or directly muck with its internals. If you need to do something and cannot because of the restrictions placed here, then please report it as an issue. If possible, we will create a way for you to implement your functionality without exposing things that should not be exposed.

๐Ÿš€ Quick Reference

Use CaseCommandDescription
Get current contextcontext()Returns the current context, creating one if needed.
Intercept eventsintercept { ... }Capture all events generated within a code block.
Run a subtestrun_subtest($NAME, \&CODE, $BUFFERED, @ARGS)Run a block as a subtest, isolating events.
Release context and returnrelease $ctx, $valueShortcut to release context and return a value.
Run code without contextno_context { ... }Hide the current context for a block.
Check if testing donetest2_is_testing_done()Returns true if testing is complete.
Get IPC instancetest2_ipc()Get the global IPC driver instance.
Set formattertest2_formatter_set($class)Set the global formatter class.

๐Ÿ“– DESCRIPTION

This package exports all the functions necessary to write and/or verify testing tools. Using these building blocks you can begin writing test tools very quickly. You are also provided with tools that help you to test the tools you write.

๐Ÿ“ SYNOPSIS

โœ๏ธ Writing a Tool

The "context()" method is your primary interface into the Test2 framework.

package My::Ok;
use Test2::API qw/context/;

our @EXPORT = qw/my_ok/;
use base 'Exporter';

# Just like ok() from Test::More
sub my_ok($;$) {
    my ($bool, $name) = @_;
    my $ctx = context(); # Get a context
    $ctx->ok($bool, $name);
    $ctx->release; # Release the context
    return $bool;
}

See Test2::API::Context for a list of methods available on the context object.

๐Ÿงช Testing Your Tools

The "intercept { ... }" tool lets you temporarily intercept all events generated by the test system:

use Test2::API qw/intercept/;

use My::Ok qw/my_ok/;

my $events = intercept {
    # These events are not displayed
    my_ok(1, "pass");
    my_ok(0, "fail");
};

As of version 1.302178 this now returns an arrayref that is also an instance of Test2::API::InterceptResult. See the Test2::API::InterceptResult documentation for details on how to best use it.

๐Ÿ”ง Other API Functions

use Test2::API qw{
    test2_init_done
    test2_stack
    test2_set_is_end
    test2_get_is_end
    test2_ipc
    test2_formatter_set
    test2_formatter
    test2_is_testing_done
};

my $init  = test2_init_done();
my $stack = test2_stack();
my $ipc   = test2_ipc();

test2_formatter_set($FORMATTER)
my $formatter = test2_formatter();

... And others ...

๐Ÿ› ๏ธ MAIN API EXPORTS

All exports are optional. You must specify subs to import.

use Test2::API qw/context intercept run_subtest/;

This is the list of exports that are most commonly needed. If you are simply writing a tool, then this is probably all you need. If you need something and you cannot find it here, then you can also look at "OTHER API EXPORTS".

These exports lack the 'test2_' prefix because of how important/common they are. Exports in the "OTHER API EXPORTS" section have the 'test2_' prefix to ensure they stand out.

๐Ÿ“Œ context(...)

Usage:

$ctx = context()
$ctx = context(%params)

The "context()" function will always return the current context. If there is already a context active, it will be returned. If there is not an active context, one will be generated. When a context is generated it will default to using the file and line number where the currently running sub was called from.

Please see "CRITICAL DETAILS" in Test2::API::Context for important rules about what you can and cannot do with a context once it is obtained.

โš ๏ธ Note: This function will throw an exception if you ignore the context object it returns.

โš ๏ธ Note: On perls 5.14+ a depth check is used to insure there are no context leaks. This cannot be safely done on older perls due to <https://rt.perl.org/Public/Bug/Display.html?id=127774>. You can forcefully enable it either by setting "$ENV{T2_CHECK_DEPTH} = 1" or "$Test2::API::DO_DEPTH_CHECK = 1" BEFORE loading Test2::API.

๐Ÿ”น Optional Parameters

All parameters to "context" are optional.

๐Ÿ“Œ release($;$)

Usage:

release $ctx;
release $ctx, ...;

This is intended as a shortcut that lets you release your context and return a value in one statement. This function will get your context, and an optional return value. It will release your context, then return your value. Scalar context is always assumed.

sub tool {
    my $ctx = context();
    ...

    return release $ctx, 1;
}

This tool is most useful when you want to return the value you get from calling a function that needs to see the current context:

my $ctx = context();
my $out = some_tool(...);
$ctx->release;
return $out;

We can combine the last 3 lines of the above like so:

my $ctx = context();
release $ctx, some_tool(...);

๐Ÿ“Œ context_do(&;@)

Usage:

sub my_tool {
    context_do {
        my $ctx = shift;

        my (@args) = @_;

        $ctx->ok(1, "pass");

        ...

        # No need to call $ctx->release, done for you on scope exit.
    } @_;
}

Using this inside your test tool takes care of a lot of boilerplate for you. It will ensure a context is acquired. It will capture and rethrow any exception. It will insure the context is released when you are done. It preserves the subroutine call context (array, scalar, void).

This is the safest way to write a test tool. The only two downsides to this are a slight performance decrease, and some extra indentation in your source. If the indentation is a problem for you then you can take a peek at the next section.

๐Ÿ“Œ no_context(&;$)

Usage:

no_context { ... };
no_context { ... } $hid;
sub my_tool(&) {
    my $code = shift;
    my $ctx = context();
    ...

    no_context {
        # Things in here will not see our current context, they get a new
        # one.

        $code->();
    };

    ...
    $ctx->release;
};

This tool will hide a context for the provided block of code. This means any tools run inside the block will get a completely new context if they acquire one. The new context will be inherited by tools nested below the one that acquired it.

This will normally hide the current context for the top hub. If you need to hide the context for a different hub you can pass in the optional $hid parameter.

๐Ÿ“Œ intercept(&)

Usage:

my $events = intercept {
    ok(1, "pass");
    ok(0, "fail");
    ...
};

This function takes a codeblock as its only argument, and it has a prototype. It will execute the codeblock, intercepting any generated events in the process. It will return an array reference with all the generated event objects. All events should be subclasses of Test2::Event.

As of version 1.302178 the events array that is returned is blssed as an Test2::API::InterceptResult instance. Test2::API::InterceptResult Provides a helpful interface for filtering and/or inspecting the events list overall, or individual events within the list.

This is intended to help you test your test code. This is not intended for people simply writing tests.

๐Ÿ“Œ run_subtest(...)

Usage:

run_subtest($NAME, \&CODE, $BUFFERED, @ARGS)

# or

run_subtest($NAME, \&CODE, \%PARAMS, @ARGS)

This will run the provided codeblock with the args in @args. This codeblock will be run as a subtest. A subtest is an isolated test state that is condensed into a single Test2::Event::Subtest event, which contains all events generated inside the subtest.

๐Ÿ”น Arguments:

๐Ÿ”น Buffered vs Unbuffered (or Streamed)

Normally all events inside and outside a subtest are sent to the formatter immediately by the hub. Sometimes it is desirable to hold off sending events within a subtest until the subtest is complete. This usually depends on the formatter being used.

Things not effected by this flag: In both cases events are generated and stored in an array. This array is eventually used to populate the "subevents" attribute on the Test2::Event::Subtest event that is generated at the end of the subtest. This flag has no effect on this part, it always happens. At the end of the subtest, the final Test2::Event::Subtest event is sent to the formatter.

Things that are effected by this flag: The "buffered" attribute of the Test2::Event::Subtest event will be set to the value of this flag. This means any formatter, listener, etc which looks at the event will know if it was buffered.

Things that are formatter dependant: Events within a buffered subtest may or may not be sent to the formatter as they happen. If a formatter fails to specify then the default is to NOT SEND the events as they are generated, instead the formatter can pull them from the "subevents" attribute. A formatter can specify by implementing the "hide_buffered()" method. If this method returns true then events generated inside a buffered subtest will not be sent independently of the final subtest event.

An example of how this is used is the Test2::Formatter::TAP formatter. For unbuffered subtests the events are rendered as they are generated. At the end of the subtest, the final subtest event is rendered, but the "subevents" attribute is ignored. For buffered subtests the opposite occurs, the events are NOT rendered as they are generated, instead the "subevents" attribute is used to render them all at once. This is useful when running subtests tests in parallel, since without it the output from subtests would be interleaved together.

โš™๏ธ OTHER API EXPORTS

Exports in this section are not commonly needed. These all have the 'test2_' prefix to help ensure they stand out. You should look at the "MAIN API EXPORTS" section before looking here. This section is one where "Great power comes with great responsibility". It is possible to break things badly if you are not careful with these.

All exports are optional. You need to list which ones you want at import time:

use Test2::API qw/test2_init_done .../;

๐Ÿ” STATUS AND INITIALIZATION STATE

These provide access to internal state and object instances.

๐Ÿ”— BEHAVIOR HOOKS

These are hooks that allow you to add custom behavior to actions taken by Test2 and tools built on top of it.

๐Ÿ”— IPC AND CONCURRENCY

These let you access, or specify, the IPC system internals.

๐Ÿ”— MANAGING FORMATTERS

These let you access, or specify, the formatters that can/should be used.

๐Ÿ“‚ OTHER EXAMPLES

See the "/Examples/" directory included in this distribution.

๐Ÿ‘๏ธ SEE ALSO

๐Ÿ”ฎ MAGIC

This package has an END block. This END block is responsible for setting the exit code based on the test results. This end block also calls the callbacks that can be added to this package.

๐Ÿ“ฆ SOURCE

The source code repository for Test2 can be found at http://github.com/Test-More/test-more/.

๐Ÿ‘ฅ MAINTAINERS

Chad Granum <exodist AT cpan.org>

โœ๏ธ AUTHORS

Chad Granum <exodist AT cpan.org>

๐Ÿ“„ COPYRIGHT

Copyright 2020 Chad Granum <exodist AT 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
๐Ÿ“› NAME ๐Ÿš€ Quick Reference ๐Ÿ“– DESCRIPTION ๐Ÿ“ SYNOPSIS
โœ๏ธ Writing a Tool ๐Ÿงช Testing Your Tools ๐Ÿ”ง Other API Functions
๐Ÿ› ๏ธ MAIN API EXPORTS
๐Ÿ“Œ context(...) ๐Ÿ“Œ release($;$) ๐Ÿ“Œ context_do(&;@) ๐Ÿ“Œ no_context(&;$) ๐Ÿ“Œ intercept(&) ๐Ÿ“Œ run_subtest(...)
โš™๏ธ OTHER API EXPORTS
๐Ÿ” STATUS AND INITIALIZATION STATE ๐Ÿ”— BEHAVIOR HOOKS ๐Ÿ”— IPC AND CONCURRENCY ๐Ÿ”— MANAGING FORMATTERS
๐Ÿ“‚ OTHER EXAMPLES ๐Ÿ‘๏ธ SEE ALSO ๐Ÿ”ฎ MAGIC ๐Ÿ“ฆ SOURCE ๐Ÿ‘ฅ MAINTAINERS โœ๏ธ AUTHORS ๐Ÿ“„ COPYRIGHT

Generated by phpman v4.9.26-5-g7740029 · Markdown · JSON · MCP Author: Che Dong Under GNU General Public License
2026-08-21 08:43 @216.73.216.45
CrawledBy Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
Valid XHTML 1.0 Transitional!Valid CSS!

^_top_^