MirOS Manual: Test(3p)


Test(3p)        Perl Programmers Reference Guide         Test(3p)

NAME

     Test - provides a simple framework for writing test scripts

SYNOPSIS

       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(...)
       );

DESCRIPTION

     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.

QUICK START GUIDE

     To write a test for your new (and probably not even done)
     module, create a new file called t/test.t (in a new t direc-
     tory). If you have multiple test files, to test the "foo",

perl v5.8.8                2005-02-05                           1

Test(3p)        Perl Programmers Reference Guide         Test(3p)

     "bar", and "baz" feature sets, then feel free to call your
     files t/foo.t, t/bar.t, and t/baz.t

     Functions

     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
             ok() and skip() 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

perl v5.8.8                2005-02-05                           2

Test(3p)        Perl Programmers Reference Guide         Test(3p)

         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" syn-
         tax).  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 arg2 is a regex that matches
         arg1, 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 con-
         sidered to look like a regex if its first and last char-
         acters 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

perl v5.8.8                2005-02-05                           3

Test(3p)        Perl Programmers Reference Guide         Test(3p)

         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 parame-
         ter. 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 note 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:

perl v5.8.8                2005-02-05                           4

Test(3p)        Perl Programmers Reference Guide         Test(3p)

           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 skip_if_true 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 skip the test, not run 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 skip_if_reason 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)" are 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 not eval the
         arguments when skipping the test, use this format:

perl v5.8.8                2005-02-05                           5

Test(3p)        Perl Programmers Reference Guide         Test(3p)

           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) } );
           }

TEST TYPES

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

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

     * TODO TESTS
         TODO tests are designed for maintaining an executable
         TODO list. These tests are expected to fail.  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.

perl v5.8.8                2005-02-05                           6

Test(3p)        Perl Programmers Reference Guide         Test(3p)

ONFAIL

       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 optional "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.  How-
     ever 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?)

BUGS and CAVEATS

     +   "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
         size of the two arrays. But don't be fooled into think-
         ing that "ok @foo, @bar" means a comparison of the

perl v5.8.8                2005-02-05                           7

Test(3p)        Perl Programmers Reference Guide         Test(3p)

         contents of two arrays -- you're comparing just 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 are
         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:

perl v5.8.8                2005-02-05                           8

Test(3p)        Perl Programmers Reference Guide         Test(3p)

           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.

ENVIRONMENT

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

NOTE

     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 simpli-
     city.  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(...)".

SEE ALSO

     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.

AUTHOR

     Copyright (c) 1998-2000 Joshua Nathaniel Pritikin.  All

perl v5.8.8                2005-02-05                           9

Test(3p)        Perl Programmers Reference Guide         Test(3p)

     rights reserved.

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

     Copyright (c) 2002-2004 and counting Sean M. Burke.

     Current maintainer: Sean M. Burke. <sburke@cpan.org>

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

perl v5.8.8                2005-02-05                          10

Generated on 2014-04-02 20:57:59 by $MirOS: src/scripts/roff2htm,v 1.79 2014/02/10 00:36:11 tg Exp $

These manual pages and other documentation are copyrighted by their respective writers; their source is available at our CVSweb, AnonCVS, and other mirrors. The rest is Copyright © 2002‒2014 The MirOS Project, Germany.
This product includes material provided by Thorsten Glaser.

This manual page’s HTML representation is supposed to be valid XHTML/1.1; if not, please send a bug report – diffs preferred.