Test2::API(3pm)

โœจ NAME โœจ

Test2::API โ€” Primary interface for writing Test2 based testing tools. ๐Ÿ’–

๐Ÿšจ INTERNALS NOTE ๐Ÿšจ

Okay bestie, real talk: 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. ๐Ÿซถ


๐ŸŒˆ 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. Periodt.

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 ...

๐ŸŒฟ ENVIRONMENT VARIABLES ๐ŸŒฟ

See Test2::Env for a list of meaningul environment variables. ๐Ÿ“


๐Ÿ‘‘ MAIN API EXPORTS ๐Ÿ‘‘

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

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 ensure 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.

  • level => $int โ€” If you must obtain a context in a sub deeper than your entry point you can use this to tell it how many EXTRA stack frames to look back. If this option is not provided the default of 0 is used.
sub third_party_tool {
    my $sub = shift;
    ... # Does not obtain a context
    $sub->();
    ...
}

third_party_tool(sub {
    my $ctx = context(level => 1);
    ...
    $ctx->release;
});
  • wrapped => $int โ€” Use this if you need to write your own tool that wraps a call to context() with the intent that it should return a context object.
sub my_context {
    my %params = ( wrapped => 0, @_ );
    $params{wrapped}++;
    my $ctx = context(%params);
    ...
    return $ctx;
}

sub my_tool {
    my $ctx = my_context();
    ...
    $ctx->release;
}

If you do not do this, then tools you call that also check for a context will notice that the context they grabbed was created at the same stack depth, which will trigger protective measures that warn you and destroy the existing context. ๐Ÿ™ˆ

  • stack => $stack โ€” Normally context() looks at the global hub stack. If you are maintaining your own Test2::API::Stack instance you may pass it in to be used instead of the global one.
  • hub => $hub โ€” Use this parameter if you want to obtain the context for a specific hub instead of whatever one happens to be at the top of the stack.
  • on_init => sub { ... } โ€” This lets you provide a callback sub that will be called ONLY if your call to context() generated a new context. The callback WILL NOT be called if context() is returning an existing context. The only argument passed into the callback will be the context object itself.
sub foo {
    my $ctx = context(on_init => sub { 'will run' });

    my $inner = sub {
        # This callback is not run since we are getting the existing
        # context from our parent sub.
        my $ctx = context(on_init => sub { 'will NOT run' });
        $ctx->release;
    }
    $inner->();

    $ctx->release;
}
  • on_release => sub { ... } โ€” This lets you provide a callback sub that will be called when the context instance is released. This callback will be added to the returned context even if an existing context is returned. If multiple calls to context add callbacks, then all will be called in reverse order when the context is finally released.
sub foo {
    my $ctx = context(on_release => sub { 'will run second' });

    my $inner = sub {
        my $ctx = context(on_release => sub { 'will run first' });

        # Neither callback runs on this release
        $ctx->release;
    }
    $inner->();

    # Both callbacks run here.
    $ctx->release;
}

๐ŸŒŸ 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 ensure the context is released when you are done. It preserves the subroutine call context (list, 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");
    ...
};

okay so this one takes a codeblock as its only argument, and yep it's got a prototype (iconic of it honestly). It runs that codeblock while intercepting every event generated inside, then hands you back an array reference stuffed with all those generated event objects. All the events should be subclasses of Test2::Event, obviously. โœจ

As of version 1.302178 the events array you get back is blessed as a Test2::API::InterceptResult instance. Test2::API::InterceptResult gives you a genuinely helpful interface for filtering and/or inspecting the whole events list, or any individual events chilling inside it. ๐Ÿซถ

This is here to help you test your test code, bestie. It is not for people who are simply out here writing tests. Different vibe entirely. ๐Ÿ’…

๐ŸŒธ run_subtest(...)

Usage, and yes there are two flavours:

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

# or

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

This runs the codeblock you give it with the args from @ARGS. And the codeblock runs as a subtest. A subtest is basically an isolated test state that gets condensed down into one single Test2::Event::Subtest event, which contains all the events generated inside it. like a little terrarium of test events, iykyk ๐ŸŒฟ

ARGUMENTS

  • $NAME โ€” the name of the subtest. what else would it be ๐ŸŽ€
  • \&CODE โ€” the code to run inside the subtest.
  • $BUFFERED or \%PARAMS โ€” okay so if this is a simple scalar then it gets treated as a boolean for the 'buffered' setting. If it's a hash reference then it's used as a parameters hash. That param hash gets used for hub construction, with the specified keys removed. ๐Ÿ‘‘

Keys that get removed and used by run_subtest:

  • 'buffered' => $bool โ€” toggle buffered status.
  • 'inherit_trace' => $bool โ€” normally the subtest hub gets pushed and the sub is allowed to generate its own root context for the hub. When this setting is turned on, a root context gets created for the hub that shares the same trace as the current context.

Set this to true if your tool is producing subtests without user-specified subs. fr fr

  • 'no_fork' => $bool โ€” defaults to off. Normally forking inside a subtest will actually fork the subtest, resulting in 2 final subtest events. This parameter turns that behaviour off, so only the original process/thread will return a final subtest event. no double trouble ๐Ÿ’€
  • @ARGS โ€” any extra arguments you want passed into the subtest code. hand 'em over ๐Ÿ“

BUFFERED VS UNBUFFERED (OR STREAMED)

Normally all events inside and outside a subtest get sent to the formatter immediately by the hub. But sometimes it's desirable to hold off sending events within a subtest until the subtest is complete. Which one you want usually depends on the formatter being used. it's giving "depends on the vibes of your formatter" โœจ

Things not affected by this flag

In both cases events are generated and stored in an array. That array is eventually used to populate the "subevents" attribute on the Test2::Event::Subtest event that gets generated at the end of the subtest. This flag has no effect on this part โ€” it always happens. non-negotiable. ๐Ÿ’…

At the end of the subtest, the final Test2::Event::Subtest event is sent to the formatter.

Things that are affected by this flag

The "buffered" attribute of the Test2::Event::Subtest event gets set to the value of this flag. So any formatter, listener, etc. that looks at the event will know if it was buffered. honest communication, love that ๐Ÿซถ

Things that are formatter dependent

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. ๐Ÿ˜ญ chaos. we don't want chaos.


๐Ÿ”ฅ OTHER API EXPORTS

Exports in this section are not commonly needed. They 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" โ€” for real, 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 give you access to internal state and object instances. peek behind the curtain bestie ๐ŸŽ€

  • $bool = test2_init_done() โ€” returns true if the stack and IPC instances have already been initialized, false if they haven't. Init happens as late as possible. It happens as soon as a tool requests the IPC instance, the formatter, or the stack. โณ
  • $bool = test2_load_done() โ€” just returns the boolean value of the loaded flag. If Test2 has finished loading this is true, otherwise false. Loading is considered complete the first time a tool requests a context.
  • test2_set_is_end()
  • test2_set_is_end($bool) โ€” toggles Test2's belief that the END phase has already started. With no arguments this sets it to true. With arguments it sets it to the first argument's value.

This is used to prevent the use of caller() in END blocks, which can cause segfaults. It's only necessary in some persistent environments that may have multiple END phases. ๐Ÿ˜ญ protect yourself.

  • $bool = test2_get_is_end() โ€” check if Test2 believes it is the END phase.
  • $stack = test2_stack() โ€” returns the global Test2::API::Stack instance. If this has not yet been initialized it will be initialized now. main character energy for a stack honestly ๐Ÿ‘‘
  • $bool = test2_is_testing_done() โ€” returns true if testing is complete and no other events should be sent. This is useful in things like warning handlers, where you might want to turn warnings into events, but need them to start acting like normal warnings when testing is done. like so:
$SIG{__WARN__} = sub {
    my ($warning) = @_;

    if (test2_is_testing_done()) {
        warn @_;
    }
    else {
        my $ctx = context();
        ...
        $ctx->release
    }
};
  • test2_ipc_disable โ€” disable IPC. bye ๐Ÿ’…
  • $bool = test2_ipc_disabled โ€” check if IPC is disabled.
  • test2_ipc_wait_enable()
  • test2_ipc_wait_disable()
  • $bool = test2_ipc_wait_enabled() โ€” these turn IPC waiting on and off, or check the current value of the flag.

Waiting is turned on by default. Waiting will cause the parent process/thread to wait until all child processes and threads are finished before exiting. You will almost never want to turn this off. ๐Ÿซถ

  • $bool = test2_no_wait()
  • test2_no_wait($bool) โ€” DISCOURAGED: this is a confusing interface, it's better to use test2_ipc_wait_enable(), test2_ipc_wait_disable() and test2_ipc_wait_enabled().

This can be used to get/set the no_wait status. Waiting is turned on by default. Waiting will cause the parent process/thread to wait until all child processes and threads are finished before exiting. You will almost never want to turn this off. (yes it says that twice, it means it ๐Ÿ˜ค)

  • $fh = test2_stdout()
  • $fh = test2_stderr() โ€” these return the filehandles that test output should be written to. They're primarily useful when writing a custom formatter and code that turns events into actual output (TAP, etc.). They return a dupe of the original filehandles that formatted output can be sent to, regardless of whatever state the currently running test may have left STDOUT and STDERR in. your own lil safe space ๐Ÿ’–
  • test2_reset_io() โ€” re-dupe the internal filehandles returned by test2_stdout() and test2_stderr() from the current STDOUT and STDERR. You shouldn't need to do this except in very peculiar situations (for example, you're testing a new formatter and you need control over where the formatter is sending its output.) ๐ŸŒ€

๐ŸŒˆ BEHAVIOR HOOKS

These are hooks that let you add custom behaviour to actions taken by Test2 and tools built on top of it. very "add your own sprinkle" of it all โœจ

  • test2_add_callback_exit(sub { ... }) โ€” adds a callback that is called after all testing is done. This is too late to add additional results; the main use of this callback is to set the exit code.
test2_add_callback_exit(
    sub {
        my ($context, $exit, \$new_exit) = @_;
        ...
    }
);

The $context passed in will be an instance of Test2::API::Context. The $exit argument will be the original exit code before anything modified it. $$new_exit is a reference to the new exit code. You may modify this to change the exit code. Please note that $$new_exit may already be different from $exit. ๐Ÿ™ˆ

  • test2_add_callback_post_load(sub { ... }) โ€” add a callback that will be called when Test2 is finished loading. This means the callback runs once, the first time a context is obtained. If Test2 has already finished loading then the callback will be run immediately. ๐ŸŽ€
  • test2_add_callback_testing_done(sub { ... }) โ€” this adds your coderef as a follow-up to the root hub after Test2 is finished loading.

This is essentially a helper to do the following:

test2_add_callback_post_load(sub {
    my $stack = test2_stack();
    $stack->top; # Ensure we have a hub
    my ($hub) = Test2::API::test2_stack->all;

    $hub->set_active(1);

    $hub->follow_up(sub { ... }); # <-- Your coderef here
});
  • test2_add_callback_context_acquire(sub { ... }) โ€” add a callback that will be called every time someone tries to acquire a context. This gets called on EVERY call to context(). It gets a single argument: a reference to the hash of parameters being used to construct the context. This is your chance to change the parameters by directly altering the hash. lowkey a superpower ๐Ÿ‘‘
test2_add_callback_context_acquire(sub {
    my $params = shift;
    $params->{level}++;
});
  • test2_add_callback_context_init(sub { ... }) โ€” drops a callback that fires every single time a brand new context gets made โœจ. It gets handed the freshly-created context as its one and only argument, bestie.
  • test2_add_callback_context_release(sub { ... }) โ€” same energy but for the other end of the lifecycle: this one runs every time a context is released ๐Ÿฆ‹. The released context is its one and only argument.
  • test2_add_callback_pre_subtest(sub { ... }) โ€” this callback goes off every time a subtest is about to run ๐ŸŽฌ. It receives the subtest name, the coderef, and any arguments. All three. No cap.
  • @list = test2_list_context_acquire_callbacks() โ€” hands you back all the context acquire callback references. All of them, in a list ๐Ÿ’….
  • @list = test2_list_context_init_callbacks() โ€” returns all the context init callback references ๐ŸŽ€.
  • @list = test2_list_context_release_callbacks() โ€” returns all the context release callback references ๐ŸŒธ.
  • @list = test2_list_exit_callbacks() โ€” returns all the exit callback references โญ.
  • @list = test2_list_post_load_callbacks() โ€” returns all the post load callback references ๐Ÿฆ‹.
  • @list = test2_list_pre_subtest_callbacks() โ€” returns all the pre-subtest callback references ๐Ÿ’–.
  • test2_add_uuid_via(sub { ... })
  • $sub = test2_add_uuid_via() โ€” okay so this one is lowkey iconic: it lets you supply your own UUID generator ๐Ÿ”ฅ. If you do, UUIDs get attached to all events, hubs, and contexts. Which is so useful for storing, tracking, and linking those objects together โ€” like little name tags at a party ๐ŸŽ€.

Your sub should always return a unique identifier. Most things will expect a proper UUID string, however nothing in Test2::API enforces this ๐Ÿ‘€ (so like, be normal about it).

The sub receives exactly 1 argument: the type of thing being tagged โ€” 'context', 'hub', or 'event'. In the future additional things may be tagged, in which case new strings will be passed in. These are purely informative โ€” you can (and usually should) ignore them ๐Ÿ™ˆ.

  • test2_add_pending_diag($diag)
  • test2_add_pending_diag($diag1, $diag2) โ€” queues up a diagnostics message that will be issued the next time a context in which a failure occured is released ๐Ÿ’….

Think of it like: "If the next bit causes a failed assertion, add this diagnostics message" โ€” that's the whole vibe fr fr.

  • @diags = test2_get_pending_diags() โ€” gets you all the current pending diagnostics messages ๐Ÿ“‹.
  • @diags = test2_clear_pending_diags() โ€” clears any pending diagnostics, and returns them to you on the way out ๐Ÿซถ.

๐ŸŒˆ IPC AND CONCURRENCY ๐ŸŒˆ

These let you access, or specify, the IPC system internals. The plumbing, bestie ๐Ÿ”ง.

  • $bool = test2_has_ipc() โ€” check if IPC is enabled. Simple vibe check โœ….
  • $ipc = test2_ipc() โ€” returns the global Test2::IPC::Driver instance ๐Ÿ‘‘. If this has not yet been initialized it will be initialized now โ€” so like, no lazy-loading avoidance here, it's happening whether you're ready or not.
  • test2_ipc_add_driver($DRIVER) โ€” adds an IPC driver to the list. Specifically, it adds the driver to the start of the list, so it jumps the queue ๐Ÿ’….
  • @drivers = test2_ipc_drivers() โ€” get the list of IPC drivers ๐Ÿš—.
  • $bool = test2_ipc_polling() โ€” check if polling is enabled ๐Ÿ‘€.
  • test2_ipc_enable_polling() โ€” turns on polling. This will cull events from other processes and threads every time a context is created ๐Ÿ”ฅ. Busy little bee.
  • test2_ipc_disable_polling() โ€” turns off IPC polling. Silence ๐Ÿคซ.
  • test2_ipc_enable_shm() โ€” legacy ๐Ÿฆ•. This is currently a no-op that returns 0;
  • test2_ipc_set_pending($uniq_val) โ€” tells other processes and events that an event is pending ๐Ÿ“ฃ. $uniq_val should be a unique value no other thread/process will generate โ€” that's the whole point, bestie, don't reuse values.
Note: after calling this test2_ipc_get_pending() will return 1. This is intentional, and not avoidable. Not a bug. Please don't file a bug ๐Ÿ’€.
  • $pending = test2_ipc_get_pending() โ€” three moods ๐Ÿ’…:
    • returns -1 if there is no way to check (assume yes)
    • returns 0 if there are (most likely) no pending events
    • returns 1 if there are (likely) pending events. Upon return it will reset โ€” nothing else will be able to see that there were pending events ๐Ÿ‘ป.
  • $timeout = test2_ipc_get_timeout()
  • test2_ipc_set_timeout($timeout) โ€” get/set the timeout value for the IPC system โฐ. This timeout is how long the IPC system will wait for child processes and threads to finish before aborting.

The default value is 30 seconds ๐Ÿ•ฐ๏ธ.


๐ŸŽ€ MANAGING FORMATTERS ๐ŸŽ€

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

  • $formatter = test2_formatter โ€” returns the global formatter class. Note: this is not an instance, bestie, it's a class ๐Ÿ™…โ€โ™€๏ธ. By default the formatter is set to Test2::Formatter::TAP.

You can override this default using the T2_FORMATTER environment variable ๐ŸŒธ.

Normally 'Test2::Formatter::' is prefixed to the value in the environment variable:

$ T2_FORMATTER='TAP' perl test.t     # Use the Test2::Formatter::TAP formatter
$ T2_FORMATTER='Foo' perl test.t     # Use the Test2::Formatter::Foo formatter

If you want to specify a full module name you use the + prefix ๐Ÿ’…:

$ T2_FORMATTER='+Foo::Bar' perl test.t     # Use the Foo::Bar formatter
  • test2_formatter_set($class_or_instance) โ€” set the global formatter class ๐Ÿ‘‘. This can only be set once. Note: this will override anything specified in the 'T2_FORMATTER' environment variable.
  • @formatters = test2_formatters() โ€” get a list of all loaded formatters ๐Ÿ“‹.
  • test2_formatter_add($class_or_instance) โ€” add a formatter to the list. The last formatter added is the one used at initialization โณ. If this is called after initialization a warning will be issued โ€” so like, respect the order of operations ๐Ÿ™ˆ.

โฐ TIME STAMPS โฐ

You can enable or disable timestamps in trace facets ๐Ÿ•. They are disabled by default for compatibility and performance reasons โ€” so no surprise timestamps showing up in your output.

  • test2_enable_trace_stamps() โ€” enable stamps in traces โœจ.
  • test2_disable_trace_stamps() โ€” disable stamps in traces ๐Ÿšซ.
  • $bool = test2_trace_stamps_enabled() โ€” check status of trace stamps.

โญ OTHER EXAMPLES โญ

See the /Examples/ directory included in this distribution ๐Ÿ“. Go look, it's cute, it's full of examples.


๐Ÿ‘€ SEE ALSO ๐Ÿ‘€

  • Test2::API::Context โ€” detailed documentation of the context object ๐Ÿ“š.
  • Test2::IPC โ€” the IPC system used for threading/fork support ๐Ÿงต.
  • Test2::Formatter โ€” formatters such as TAP live here ๐ŸŽ€.
  • Test2::Event โ€” events live in this namespace โœจ.
  • Test2::Hub โ€” all events eventually funnel through a hub. Custom hubs are how intercept() and run_subtest() are implemented ๐Ÿ‘‘.

๐Ÿ”ฎ 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. So like, that's the finale, that's where everything wraps up ๐Ÿ’–.


๐Ÿ’œ SOURCE ๐Ÿ’œ

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


๐Ÿซถ MAINTAINERS ๐Ÿซถ

Chad Granum <exodist@cpan.org>


๐ŸŒธ AUTHORS ๐ŸŒธ

Chad Granum <exodist@cpan.org>


Copyright 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 <https://dev.perl.org/licenses/


okay bestie that's the whole page, we did it ๐ŸŽ‰ โ€” this was perl v5.42.3, dated 2026-11-03, and it is officially Test2::API(3pm). go write some tests, you absolute icon ๐Ÿ‘‘๐Ÿ’…

๐Ÿ“ฆ where this page comes from