Test(3)               User Contributed Perl Documentation              Test(3)



NNAAMMEE
       Test − provides a simple framework for writing test scripts

SSYYNNOOPPSSIISS
         use strict;
         use Test;

         # use a BEGIN block so we print our plan before MyModule is loaded
         BEGIN { plan tests => 14, todo => [3,4] }

         # load your module...
         use MyModule;

         # Helpful notes.  All note−lines must start with a "#".
         print "# I'm testing MyModule version $MyModule::VERSION\n";

         ok(0); # failure
         ok(1); # success

         ok(0); # ok, expected failure (see todo list, above)
         ok(1); # surprise success!

         ok(0,1);             # failure: '0' ne '1'
         ok('broke','fixed'); # failure: 'broke' ne 'fixed'
         ok('fixed','fixed'); # success: 'fixed' eq 'fixed'
         ok('fixed',qr/x/);   # success: 'fixed' =~ qr/x/

         ok(sub { 1+1 }, 2);  # success: '2' eq '2'
         ok(sub { 1+1 }, 3);  # failure: '2' ne '3'

         my @list = (0,0);
         ok @list, 3, "\@list=".join(',',@list);      #extra notes
         ok 'segmentation fault', '/(?i)success/';    #regex match

         skip(
           $^O =~ m/MSWin/ ? "Skip if MSWin" : 0,  # whether to skip
           $foo, $bar  # arguments just like for ok(...)
         );
         skip(
           $^O =~ m/MSWin/ ? 0 : "Skip unless MSWin",  # whether to skip
           $foo, $bar  # arguments just like for ok(...)
         );

DDEESSCCRRIIPPTTIIOONN
       This module simplifies the task of writing test files for Perl modules,
       such that their output is in the format that Test::Harness expects to
       see.

QQUUIICCKK SSTTAARRTT GGUUIIDDEE
       To write a test for your new (and probably not even done) module,
       create a new file called _t_/_t_e_s_t_._t (in a new _t directory). If you have
       multiple test files, to test the "foo", "bar", and "baz" feature sets,
       then feel free to call your files _t_/_f_o_o_._t, _t_/_b_a_r_._t, and _t_/_b_a_z_._t

   FFuunnccttiioonnss
       This module defines three public functions, "plan(...)", "ok(...)", and
       "skip(...)".  By default, all three are exported by the "use Test;"
       statement.

       "plan(...)"
                BEGIN { plan %theplan; }

           This should be the first thing you call in your test script.  It
           declares your testing plan, how many there will be, if any of them
           should be allowed to fail, and so on.

           Typical usage is just:

                use Test;
                BEGIN { plan tests => 23 }

           These are the things that you can put in the parameters to plan:

           "tests => number"
               The number of tests in your script.  This means all _o_k_(_) and
               _s_k_i_p_(_) calls.

           "todo => [1,5,14]"
               A reference to a list of tests which are allowed to fail.  See
               "TODO TESTS".

           "onfail => sub { ... }"
           "onfail => \&some_sub"
               A subroutine reference to be run at the end of the test script,
               if any of the tests fail.  See "ONFAIL".

           You must call "plan(...)" once and only once.  You should call it
           in a "BEGIN {...}" block, like so:

                BEGIN { plan tests => 23 }

       "ok(...)"
             ok(1 + 1 == 2);
             ok($have, $expect);
             ok($have, $expect, $diagnostics);

           This function is the reason for "Test"’s existence.  It’s the basic
           function that handles printing ""ok"" or ""not ok"", along with the
           current test number.  (That’s what "Test::Harness" wants to see.)

           In its most basic usage, "ok(...)" simply takes a single scalar
           expression.  If its value is true, the test passes; if false, the
           test fails.  Examples:

               # Examples of ok(scalar)

               ok( 1 + 1 == 2 );           # ok if 1 + 1 == 2
               ok( $foo =~ /bar/ );        # ok if $foo contains 'bar'
               ok( baz($x + $y) eq 'Armondo' );    # ok if baz($x + $y) returns
                                                   # 'Armondo'
               ok( @a == @b );             # ok if @a and @b are the same length

           The expression is evaluated in scalar context.  So the following
           will work:

               ok( @stuff );                       # ok if @stuff has any elements
               ok( !grep !defined $_, @stuff );    # ok if everything in @stuff is
                                                   # defined.

           A special case is if the expression is a subroutine reference (in
           either "sub {...}" syntax or "\&foo" syntax).  In that case, it is
           executed and its value (true or false) determines if the test
           passes or fails.  For example,

               ok( sub {   # See whether sleep works at least passably
                 my $start_time = time;
                 sleep 5;
                 time() − $start_time  >= 4
               });

           In its two‐argument form, "ok(arg1, arg2)" compares the two scalar
           values to see if they match.  They match if both are undefined, or
           if _a_r_g_2 is a regex that matches _a_r_g_1, or if they compare equal with
           "eq".

               # Example of ok(scalar, scalar)

               ok( "this", "that" );               # not ok, 'this' ne 'that'
               ok( "", undef );                    # not ok, "" is defined

           The second argument is considered a regex if it is either a regex
           object or a string that looks like a regex.  Regex objects are
           constructed with the qr// operator in recent versions of perl.  A
           string is considered to look like a regex if its first and last
           characters are "/", or if the first character is "m" and its second
           and last characters are both the same non‐alphanumeric non‐
           whitespace character.  These regexp

           Regex examples:

               ok( 'JaffO', '/Jaff/' );    # ok, 'JaffO' =~ /Jaff/
               ok( 'JaffO', 'm|Jaff|' );   # ok, 'JaffO' =~ m|Jaff|
               ok( 'JaffO', qr/Jaff/ );    # ok, 'JaffO' =~ qr/Jaff/;
               ok( 'JaffO', '/(?i)jaff/ ); # ok, 'JaffO' =~ /jaff/i;

           If either (or both!) is a subroutine reference, it is run and used
           as the value for comparing.  For example:

               ok sub {
                   open(OUT, ">x.dat") || die $!;
                   print OUT "\x{e000}";
                   close OUT;
                   my $bytecount = −s 'x.dat';
                   unlink 'x.dat' or warn "Can't unlink : $!";
                   return $bytecount;
                 },
                 4
               ;

           The above test passes two values to "ok(arg1, arg2)" ‐‐ the first a
           coderef, and the second is the number 4.  Before "ok" compares
           them, it calls the coderef, and uses its return value as the real
           value of this parameter. Assuming that $bytecount returns 4, "ok"
           ends up testing "4 eq 4".  Since that’s true, this test passes.

           Finally, you can append an optional third argument, in
           "ok(arg1,arg2, note)", where _n_o_t_e is a string value that will be
           printed if the test fails.  This should be some useful information
           about the test, pertaining to why it failed, and/or a description
           of the test.  For example:

               ok( grep($_ eq 'something unique', @stuff), 1,
                   "Something that should be unique isn't!\n".
                   '@stuff = '.join ', ', @stuff
                 );

           Unfortunately, a note cannot be used with the single argument style
           of "ok()".  That is, if you try "ok(arg1, note)", then "Test" will
           interpret this as "ok(arg1, arg2)", and probably end up testing
           "arg1 eq arg2" ‐‐ and that’s not what you want!

           All of the above special cases can occasionally cause some
           problems.  See "BUGS and CAVEATS".

       "skip(skip_if_true, args...)"
           This is used for tests that under some conditions can be skipped.
           It’s basically equivalent to:

             if( $skip_if_true ) {
               ok(1);
             } else {
               ok( args... );
             }

           ...except that the ok(1) emits not just ""ok testnum"" but actually
           ""ok testnum # skip_if_true_value"".

           The arguments after the _s_k_i_p___i_f___t_r_u_e are what is fed to "ok(...)"
           if this test isn’t skipped.

           Example usage:

             my $if_MSWin =
               $^O =~ m/MSWin/ ? 'Skip if under MSWin' : '';

             # A test to be skipped if under MSWin (i.e., run except under MSWin)
             skip($if_MSWin, thing($foo), thing($bar) );

           Or, going the other way:

             my $unless_MSWin =
               $^O =~ m/MSWin/ ? '' : 'Skip unless under MSWin';

             # A test to be skipped unless under MSWin (i.e., run only under MSWin)
             skip($unless_MSWin, thing($foo), thing($bar) );

           The tricky thing to remember is that the first parameter is true if
           you want to _s_k_i_p the test, not _r_u_n it; and it also doubles as a
           note about why it’s being skipped. So in the first codeblock above,
           read the code as "skip if MSWin ‐‐ (otherwise) test whether
           "thing($foo)" is "thing($bar)"" or for the second case, "skip
           unless MSWin...".

           Also, when your _s_k_i_p___i_f___r_e_a_s_o_n string is true, it really should
           (for backwards compatibility with older Test.pm versions) start
           with the string "Skip", as shown in the above examples.

           Note that in the above cases, "thing($foo)" and "thing($bar)" _a_r_e
           evaluated ‐‐ but as long as the "skip_if_true" is true, then we
           "skip(...)" just tosses out their value (i.e., not bothering to
           treat them like values to "ok(...)".  But if you need to _n_o_t eval
           the arguments when skipping the test, use this format:

             skip( $unless_MSWin,
               sub {
                 # This code returns true if the test passes.
                 # (But it doesn't even get called if the test is skipped.)
                 thing($foo) eq thing($bar)
               }
             );

           or even this, which is basically equivalent:

             skip( $unless_MSWin,
               sub { thing($foo) }, sub { thing($bar) }
             );

           That is, both are like this:

             if( $unless_MSWin ) {
               ok(1);  # but it actually appends "# $unless_MSWin"
                       #  so that Test::Harness can tell it's a skip
             } else {
               # Not skipping, so actually call and evaluate...
               ok( sub { thing($foo) }, sub { thing($bar) } );
             }

TTEESSTT TTYYPPEESS
       ·   NORMAL TESTS

           These tests are expected to succeed.  Usually, most or all of your
           tests are in this category.  If a normal test doesn’t succeed, then
           that means that something is _w_r_o_n_g.

       ·   SKIPPED TESTS

           The "skip(...)" function is for tests that might or might not be
           possible to run, depending on the availability of platform‐specific
           features.  The first argument should evaluate to true (think "yes,
           please skip") if the required feature is _n_o_t available.  After the
           first argument, "skip(...)" works exactly the same way as "ok(...)"
           does.

       ·   TODO TESTS

           TODO tests are designed for maintaining an eexxeeccuuttaabbllee TTOODDOO lliisstt.
           These tests are _e_x_p_e_c_t_e_d _t_o _f_a_i_l_.  If a TODO test does succeed,
           then the feature in question shouldn’t be on the TODO list, now
           should it?

           Packages should NOT be released with succeeding TODO tests.  As
           soon as a TODO test starts working, it should be promoted to a
           normal test, and the newly working feature should be documented in
           the release notes or in the change log.

OONNFFAAIILL
         BEGIN { plan test => 4, onfail => sub { warn "CALL 911!" } }

       Although test failures should be enough, extra diagnostics can be
       triggered at the end of a test run.  "onfail" is passed an array ref of
       hash refs that describe each test failure.  Each hash will contain at
       least the following fields: "package", "repetition", and "result".
       (You shouldn’t rely on any other fields being present.)  If the test
       had an expected value or a diagnostic (or "note") string, these will
       also be included.

       The _o_p_t_i_o_n_a_l "onfail" hook might be used simply to print out the
       version of your package and/or how to report problems.  It might also
       be used to generate extremely sophisticated diagnostics for a
       particularly bizarre test failure.  However it’s not a panacea.  Core
       dumps or other unrecoverable errors prevent the "onfail" hook from
       running.  (It is run inside an "END" block.)  Besides, "onfail" is
       probably over‐kill in most cases.  (Your test code should be simpler
       than the code it is testing, yes?)

BBUUGGSS aanndd CCAAVVEEAATTSS
       ·   "ok(...)"’s special handing of strings which look like they might
           be regexes can also cause unexpected behavior.  An innocent:

               ok( $fileglob, '/path/to/some/*stuff/' );

           will fail, since Test.pm considers the second argument to be a
           regex!  The best bet is to use the one‐argument form:

               ok( $fileglob eq '/path/to/some/*stuff/' );

       ·   "ok(...)"’s use of string "eq" can sometimes cause odd problems
           when comparing numbers, especially if you’re casting a string to a
           number:

               $foo = "1.0";
               ok( $foo, 1 );      # not ok, "1.0" ne 1

           Your best bet is to use the single argument form:

               ok( $foo == 1 );    # ok "1.0" == 1

       ·   As you may have inferred from the above documentation and examples,
           "ok"’s prototype is "($;$$)" (and, incidentally, "skip"’s is
           "($;$$$)"). This means, for example, that you can do "ok @foo,
           @bar" to compare the _s_i_z_e of the two arrays. But don’t be fooled
           into thinking that "ok @foo, @bar" means a comparison of the
           contents of two arrays ‐‐ you’re comparing _j_u_s_t the number of
           elements of each. It’s so easy to make that mistake in reading "ok
           @foo, @bar" that you might want to be very explicit about it, and
           instead write "ok scalar(@foo), scalar(@bar)".

       ·   This almost definitely doesn’t do what you expect:

                ok $thingy−>can('some_method');

           Why?  Because "can" returns a coderef to mean "yes it can (and the
           method is this...)", and then "ok" sees a coderef and thinks you’re
           passing a function that you want it to call and consider the truth
           of the result of!  I.e., just like:

                ok $thingy−>can('some_method')−>();

           What you probably want instead is this:

                ok $thingy−>can('some_method') && 1;

           If the "can" returns false, then that is passed to "ok".  If it
           returns true, then the larger expression
           "$thingy−>can('some_method') && 1" returns 1, which "ok" sees as a
           simple signal of success, as you would expect.

       ·   The syntax for "skip" is about the only way it can be, but it’s
           still quite confusing.  Just start with the above examples and
           you’ll be okay.

           Moreover, users may expect this:

             skip $unless_mswin, foo($bar), baz($quux);

           to not evaluate "foo($bar)" and "baz($quux)" when the test is being
           skipped.  But in reality, they _a_r_e evaluated, but "skip" just won’t
           bother comparing them if $unless_mswin is true.

           You could do this:

             skip $unless_mswin, sub{foo($bar)}, sub{baz($quux)};

           But that’s not terribly pretty.  You may find it simpler or clearer
           in the long run to just do things like this:

             if( $^O =~ m/MSWin/ ) {
               print "# Yay, we're under $^O\n";
               ok foo($bar), baz($quux);
               ok thing($whatever), baz($stuff);
               ok blorp($quux, $whatever);
               ok foo($barzbarz), thang($quux);
             } else {
               print "# Feh, we're under $^O.  Watch me skip some tests...\n";
               for(1 .. 4) { skip "Skip unless under MSWin" }
             }

           But be quite sure that "ok" is called exactly as many times in the
           first block as "skip" is called in the second block.

EENNVVIIRROONNMMEENNTT
       If "PERL_TEST_DIFF" environment variable is set, it will be used as a
       command for comparing unexpected multiline results.  If you have GNU
       diff installed, you might want to set "PERL_TEST_DIFF" to "diff −u".
       If you don’t have a suitable program, you might install the
       "Text::Diff" module and then set "PERL_TEST_DIFF" to be "perl
       −MText::Diff −e 'print diff(@ARGV)'".  If "PERL_TEST_DIFF" isn’t set
       but the "Algorithm::Diff" module is available, then it will be used to
       show the differences in multiline results.

NNOOTTEE
       A past developer of this module once said that it was no longer being
       actively developed.  However, rumors of its demise were greatly
       exaggerated.  Feedback and suggestions are quite welcome.

       Be aware that the main value of this module is its simplicity.  Note
       that there are already more ambitious modules out there, such as
       Test::More and Test::Unit.

       Some earlier versions of this module had docs with some confusing
       typoes in the description of "skip(...)".

SSEEEE AALLSSOO
       Test::Harness

       Test::Simple, Test::More, Devel::Cover

       Test::Builder for building your own testing library.

       Test::Unit is an interesting XUnit‐style testing library.

       Test::Inline and SelfTest let you embed tests in code.

AAUUTTHHOORR
       Copyright (c) 1998−2000 Joshua Nathaniel Pritikin.

       Copyright (c) 2001−2002 Michael G. Schwern.

       Copyright (c) 2002−2004 Sean M. Burke.

       Current maintainer: Jesse Vincent. <jesse@bestpractical.com>

       This package is free software and is provided "as is" without express
       or implied warranty.  It may be used, redistributed and/or modified
       under the same terms as Perl itself.



perl v5.8.9                       2009‐04‐29                           Test(3)
