DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH
 

/usr/man/cat.3/Test.3.Z(/usr/man/cat.3/Test.3.Z)





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;

         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'
         ok(0, int(rand(2));  # (just kidding :-)

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

         skip($feature_is_missing, ...);    #do platform specific test


DESCRIPTION

       STOP! If you are writing a new test, we highly suggest you use the new
       Test::Simple and Test::More modules instead.

       Test::Harness expects to see particular output when it executes tests.
       This module aims to make writing proper test scripts just a little bit
       easier (and less error prone :-).

       Functions

       All the following are exported by Test by default.

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

           Typical usage is just:

                use Test;
                BEGIN { plan tests => 23 }

           Things you can put in the plan:

                tests          The number of tests in your script.
                               This means all ok() and skip() calls.
                todo           A reference to a list of tests which are allowed
                               to fail.  See L</TODO TESTS>.
                onfail         A subroutine reference to be run at the end of
                               the test script should any of the tests fail.
                               See L</ONFAIL>.

           You must call plan() once and only once.

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

           This is the reason for Test's existance.  Its the basic function
           that handles printing "ok" or "not ok" along with the current test
           number.

           In its most basic usage, it simply takes an expression.  If its
           true, the test passes, if false, the test fails.  Simp.

               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
           that case, it is executed and its value (true or false) determines
           if the test passes or fails.

           In its two argument form it compares the two values to see if they
           equal (with "eq").

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

           If either is a subroutine reference, that is run and used as a com-
           parison.

           Should $expect either be a regex reference (ie. qr//) or a string
           that looks like a regex (ie. '/foo/') ok() will perform a pattern
           match against it rather than using eq.

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

           Finally, an optional set of $diagnostics will be printed should the
           test fail.  This should usually be some useful information about
           the test pertaining to why it failed or perhaps a description of
           the test.  Or both.

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

           Unfortunately, a diagnostic cannot be used with the single argument
           style of ok().

           All these special cases can cause some problems.  See "BUGS and
           CAVEATS".


TEST TYPES

       o NORMAL TESTS
           These tests are expected to succeed.  If they don't something's
           screwed up!

       o SKIPPED TESTS
           Skip 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 not available.  After the first argu-
           ment, skip works exactly the same way as do normal tests.

       o TODO TESTS
           TODO tests are designed for maintaining an executable TODO list.
           These tests are expected NOT to succeed.  If a TODO test does suc-
           ceed, the feature in question should not 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 nor-
           mal test and the newly working feature should be documented in the
           release notes or change log.


ONFAIL

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

       While test failures should be enough, extra diagnostics can be trig-
       gered 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".
       (The file, line, and test number are not included because their corre-
       spondence to a particular test is tenuous.)  If the test had an
       expected value or a diagnostic string, these will also be included.

       The optional "onfail" hook might be used simply to print out the ver-
       sion 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?)


BUGS and CAVEATS

       ok()'s special handling of subroutine references is an unfortunate
       "feature" that can't be removed due to compatibility.

       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

       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 a regex.
       Again, best bet is to use the single argument form:

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


NOTE

       This module is no longer actively being developed, only bug fixes and
       small tweaks (I'll still accept patches).  If you desire additional
       functionality, consider Test::More or Test::Unit.


SEE ALSO

       Test::Simple, Test::More, Test::Harness, 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 rights
       reserved.  Copyright (c) 2001-2002 Michael G Schwern.

       Current maintainer, Michael G Schwern <schwern@pobox.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.0                       2002-06-01                           Test(3)
See also Test::Builder(3):  man 3 Test::Builder
See also Test::Harness(3):  man 3 Test::Harness
See also Test::Harness::Assert(3):  man 3 Test::Harness::Assert
See also Test::Harness::Iterator(3):  man 3 Test::Harness::Iterator
See also Test::Harness::Straps(3):  man 3 Test::Harness::Straps
See also Test::More(3):  man 3 Test::More
See also Test::Simple(3):  man 3 Test::Simple
See also Test::Tutorial(3):  man 3 Test::Tutorial

Man(1) output converted with man2html