"die_on_fail"

 die_on_fail;
 is_deeply $foo, bar, '... we throw an exception if this fails';

This function, if called, will cause the test program to throw a Test::Most::Exception, effectively halting the test.

"bail_on_fail"

 bail_on_fail;
 is_deeply $foo, bar, '... we bail out if this fails';

This function, if called, will cause the test suite to BAIL_OUT() if any tests fail after it.

"restore_fail"

 die_on_fail;
 is_deeply $foo, bar, '... we throw an exception if this fails';
 restore_fail;
 cmp_bag(\@got, \@bag, '... we will not throw an exception if this fails';

This restores the original test failure behavior, so subsequent tests will no longer throw an exception or BAIL_OUT().

"set_failure_handler"

If you prefer other behavior to 'die_on_fail' or 'bail_on_fail', you can set your own failure handler:

 set_failure_handler( sub {
     my $builder = shift;
     if ( $builder && $builder->{Test_Results}[-1] =~ /critical/ ) {
        send_admin_email("critical failure in tests");
     }
 } );

It receives the "Test::Builder" instance as its only argument.

Important: Note that if the failing test is the very last test run, then the $builder will likely be undefined. This is an unfortunate side effect of how "Test::Builder" has been designed.

"explain"

Similar to "note()", the output will only be seen by the user by using the "-v" switch with "prove" or reading the raw TAP.

Unlike "note()", any reference in the argument list is automatically expanded using "Data::Dumper". Thus, instead of this:

 my $self = Some::Object->new($id);
 use Data::Dumper;
 explain 'I was just created', Dumper($self);

You can now just do this:

 my $self = Some::Object->new($id);
 explain 'I was just created:  ', $self;

That output will look similar to:

 I was just created: bless( {
   'id' => 2,
   'stack' => []
 }, 'Some::Object' )

Note that the "dumpered" output has the "Data::Dumper" variables $Indent, "Sortkeys" and "Terse" all set to the value of 1 (one). This allows for a much cleaner diagnostic output and at the present time cannot be overridden.

Note that Test::More's "explain" acts differently. This "explain" is equivalent to "note explain" in Test::More.

"show"

Experimental. Just like "explain", but also tries to show you the lexical variable names:

 my $var   = 3;
 my @array = qw/ foo bar /;
 show $var, \@array;
 __END__
 $var = 3;
 @array = [
     'foo',
     'bar'
 ];

It will show $VAR1, $VAR2 ... $VAR_N for every variable it cannot figure out the variable name to:

 my @array = qw/ foo bar /;
 show @array;
 __END__
 $VAR1 = 'foo';
 $VAR2 = 'bar';

Note that this relies on Data::Dumper::Names version 0.03 or greater. If this is not present, it will warn and call explain instead. Also, it can only show the names for lexical variables. Globals such as %ENV or "%@" are not accessed via PadWalker and thus cannot be shown. It would be nice to find a workaround for this.

"always_explain" and "always_show"

These are identical to "explain" and "show", but like Test::More's "diag" function, these will always emit output, regardless of whether or not you're in verbose mode.

"all_done"

DEPRECATED. Use the new "done_testing()" (added in Test::More since 0.87_01). Instead. We're leaving this in here for a long deprecation cycle. After a while, we might even start warning.

If the plan is specified as "defer_plan", you may call &all_done at the end of the test with an optional test number. This lets you set the plan without knowing the plan before you run the tests.

If you call it without a test number, the tests will still fail if you don't get to the end of the test. This is useful if you don't want to specify a plan but the tests exit unexpectedly. For example, the following would pass with "no_plan" but fails with "all_done".

 use Test::More 'defer_plan';
 ok 1;
 exit;
 ok 2;
 all_done;

See "Deferred plans" for more information.

"timeit"

Prototype: "timeit(&;$)"

This function will warn if "Time::HiRes" is not installed. The test will still be run, but no timing information will be displayed.

 use Test::Most 'timeit';
 timeit { is expensive_function(), $some_value, $message }
    "expensive_function()";
 timeit { is expensive_function(), $some_value, $message };

"timeit" accepts a code reference and an optional message. After the test is run, will "explain" the time of the function using "Time::HiRes". If a message is supplied, it will be formatted as:

  sprintf "$message: took %s seconds" => $time;

Otherwise, it will be formatted as:

  sprintf "$filename line $line: took %s seconds" => $time;

Import list

 use Test::Most 'die', tests => 7;
 use Test::Most qw< no_plan bail >;

If "die" or "bail" is anywhere in the import list, the test program/suite will throw a "Test::Most::Exception" or "BAIL_OUT()" as appropriate the first time a test fails. Calling "restore_fail" anywhere in the test program will restore the original behavior (not throwing an exception or bailing out).

Functions

 use Test::Most 'no_plan';
 ok $bar, 'The test suite will continue if this passes';
 die_on_fail;
 is_deeply $foo, bar, '... we throw an exception if this fails';
 restore_fail;
 ok $baz, 'The test suite will continue if this passes';

The "die_on_fail" and "bail_on_fail" functions will automatically set the desired behavior at runtime.

Environment variables

 DIE_ON_FAIL=1 prove t/
 BAIL_ON_FAIL=1 prove t/

If the "DIE_ON_FAIL" or "BAIL_ON_FAIL" environment variables are true, any tests which use "Test::Most" will throw an exception or call BAIL_OUT on test failure.

Moose

It used to be that this module would produce a warning when used with Moose:

    Prototype mismatch: sub main::blessed ($) vs none

This was because Test::Deep exported a "blessed()" function by default, but its prototype did not match the Moose version's prototype. We now exclude the Test::Deep version by default. If you need it, you can call the fully-qualified version or request it on the command line:

    use Test::Most 'blessed';

Note that as of version 0.34, "reftype" is also excluded from "Test::Deep"'s import list. This was causing issues with people trying to use "Scalar::Util"'s "reftype" function.

Excluding Test Modules

Sometimes you want a exclude a particular test module. For example, Test::Deep, when used with Moose, produces the following warning:

    Prototype mismatch: sub main::blessed ($) vs none

You can exclude this with by adding the module to the import list with a '-' symbol in front:

    use Test::Most tests => 42, '-Test::Deep';

See <https://rt.cpan.org/Ticket/Display.html?id=54362&results=e73ff63c5bf9ba0f796efdba5773cf3f> for more information.

Excluding Test Symbols

Sometimes you don't want to exclude an entire test module, but just a particular symbol that is causing issues You can exclude the symbol(s) in the standard way, by specifying the symbol in the import list with a '!' in front:

    use Test::Most tests => 42, '!throws_ok';

Deferred plans

DEPRECATED and will be removed in some future release of this module. Using "defer_plan" will "carp()". Use "done_testing()" from Test::More instead.

 use Test::Most qw<defer_plan>;
 use My::Tests;
 my $test_count = My::Tests->run;
 all_done($test_count);

Sometimes it's difficult to know the plan up front, but you can calculate the plan as your tests run. As a result, you want to defer the plan until the end of the test. Typically, the best you can do is this:

 use Test::More 'no_plan';
 use My::Tests;
 My::Tests->run;

But when you do that, "Test::Builder" merely asserts that the number of tests you ran is the number of tests. Until now, there was no way of asserting that the number of tests you expected is the number of tests unless you do so before any tests have run. This fixes that problem.

One-stop shopping

We generally require the latest stable versions of various test modules. Why? Because they have bug fixes and new features. You don't want to have to keep remembering them, so periodically we'll release new versions of Test::Most just for bug fixes.

"use ok"

We do not bundle Test::use::ok, though it's been requested. That's because "use_ok" is broken, but Test::use::ok is also subtly broken (and a touch harder to fix). See <http://use.perl.org/~Ovid/journal/39859> for more information.

If you want to test if you can use a module, just use it. If it fails, the test will still fail and that's the desired result.

Deferred plans

Sometimes you don't know the number of tests you will run when you use "Test::More". The "plan()" function allows you to delay specifying the plan, but you must still call it before the tests are run. This is an error:

 use Test::More;
 my $tests = 0;
 foreach my $test (
     my $count = run($test); # assumes tests are being run
     $tests += $count;
 }
 plan($tests);

The way around this is typically to use 'no_plan' and when the tests are done, "Test::Builder" merely sets the plan to the number of tests run. We'd like for the programmer to specify this number instead of letting "Test::Builder" do it. However, "Test::Builder" internals are a bit difficult to work with, so we're delaying this feature.

Cleaner skip()

 if ( $some_condition ) {
     skip $message, $num_tests;
 }
 else {
     # run those tests
 }

That would be cleaner and I might add it if enough people want it.