Provided by: libtest-most-perl_0.34-1_all bug

NAME

       Test::Most - Most commonly needed test functions and features.

VERSION

       Version 0.34

SYNOPSIS

       Instead of this:

           use strict;
           use warnings;
           use Test::Exception 0.88;
           use Test::Differences 0.500;
           use Test::Deep 0.106;
           use Test::Warn 0.11;
           use Test::More tests => 42;

       You type this:

           use Test::Most tests => 42;

DESCRIPTION

       Test::Most exists to reduce boilerplate and to make your testing life easier.  We provide
       "one stop shopping" for most commonly used testing modules.  In fact, we often require the
       latest versions so that you get bug fixes through Test::Most and don't have to keep
       upgrading these modules separately.

       This module provides you with the most commonly used testing functions, along with
       automatically turning on strict and warning and gives you a bit more fine-grained control
       over your test suite.

           use Test::Most tests => 4, 'die';

           ok 1, 'Normal calls to ok() should succeed';
           is 2, 2, '... as should all passing tests';
           eq_or_diff [3], [4], '... but failing tests should die';
           ok 4, '... will never get to here';

       As you can see, the "eq_or_diff" test will fail.  Because 'die' is in the import list, the
       test program will halt at that point.

       If you do not want strict and warnings enabled, you must explicitly disable them.  Thus,
       you must be explicit about what you want and no longer need to worry about accidentally
       forgetting them.

           use Test::Most tests => 4;
           no strict;
           no warnings;

EXPORT

       All functions from the following modules will automatically be exported into your
       namespace:

       ·   Test::More

       ·   Test::Exception

       ·   Test::Differences

       ·   Test::Deep

       ·   Test::Warn

       Functions which are optionally exported from any of those modules must be referred to by
       their fully-qualified name:

         Test::Deep::render_stack( $var, $stack );

FUNCTIONS

       Several other functions are also automatically exported:

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

EXPORT ON DEMAND

       The following will be exported only if requested:

   "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;

DIE OR BAIL ON FAIL

       Sometimes you want your test suite to throw an exception or BAIL_OUT() if a test fails.
       In order to provide maximum flexibility, there are three ways to accomplish each of these.

   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.

MISCELLANEOUS

   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.

RATIONALE

       People want more control over their test suites.  Sometimes when you see hundreds of tests
       failing and whizzing by, you want the test suite to simply halt on the first failure.
       This module gives you that control.

       As for the reasons for the four test modules chosen, I ran code over a local copy of the
       CPAN to find the most commonly used testing modules.  Here's the top twenty as of January
       2010 (the numbers are different because we're now counting distributions which use a given
       module rather than simply the number of times a module is used).

           1   Test::More                          14111
           2   Test                                 1736
           3   Test::Exception                       744
           4   Test::Simple                          331
           5   Test::Pod                             328
           6   Test::Pod::Coverage                   274
           7   Test::Perl::Critic                    248
           8   Test::Base                            228
           9   Test::NoWarnings                      155
           10  Test::Distribution                    142
           11  Test::Kwalitee                        138
           12  Test::Deep                            128
           13  Test::Warn                            127
           14  Test::Differences                     102
           15  Test::Spelling                        101
           16  Test::MockObject                       87
           17  Test::Builder::Tester                  84
           18  Test::WWW::Mechanize::Catalyst         79
           19  Test::UseAllModules                    63
           20  Test::YAML::Meta                       61

       Test::Most is number 24 on that list, if you're curious.  See
       <http://blogs.perl.org/users/ovid/2010/01/most-popular-testing-modules---january-2010.html>.

       The modules chosen seemed the best fit for what "Test::Most" is trying to do.  As of 0.02,
       we've added Test::Warn by request.  It's not in the top ten, but it's a great and useful
       module.

AUTHOR

       Curtis Poe, "<ovid at cpan.org>"

BUGS

       Please report any bugs or feature requests to "bug-test-extended at rt.cpan.org", or
       through the web interface at <http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Test-Most>.
       I will be notified, and then you'll automatically be notified of progress on your bug as I
       make changes.

SUPPORT

       You can find documentation for this module with the perldoc command.

           perldoc Test::Most

       You can also look for information at:

       ·   RT: CPAN's request tracker

           <http://rt.cpan.org/NoAuth/Bugs.html?Dist=Test-Most>

       ·   AnnoCPAN: Annotated CPAN documentation

           <http://annocpan.org/dist/Test-Most>

       ·   CPAN Ratings

           <http://cpanratings.perl.org/d/Test-Most>

       ·   Search CPAN

           <http://search.cpan.org/dist/Test-Most>

TODO

   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.

CAVEATS

       Because of how Perl handles arguments, and because diagnostics are not really part of the
       Test Anything Protocol, what actually happens internally is that we note that a test has
       failed and we throw an exception or bail out as soon as the next test is called (but
       before it runs).  This means that its arguments are automatically evaluated before we can
       take action:

        use Test::Most qw<no_plan die>;

        ok $foo, 'Die if this fails';
        ok factorial(123456),
          '... but wait a loooong time before you throw an exception';

ACKNOWLEDGEMENTS

       Many thanks to "perl-qa" for arguing about this so much that I just went ahead and did it
       :)

       Thanks to Aristotle for suggesting a better way to die or bailout.

       Thanks to 'swillert' (<http://use.perl.org/~swillert/>) for suggesting a better
       implementation of my "dumper explain" idea (<http://use.perl.org/~Ovid/journal/37004>).

COPYRIGHT & LICENSE

       Copyright 2008 Curtis Poe, all rights reserved.

       This program is free software; you can redistribute it and/or modify it under the same
       terms as Perl itself.