Chris Prather > XML-SAX-Machines-0.44 > Test

Download:
XML-SAX-Machines-0.44.tar.gz

Dependencies

Annotate this POD

Website

CPAN RT

New  6
Open  0
View/Report Bugs
Module Version: 1.26   Source  

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 directory). If you have multiple test files, to test the "foo", "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 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 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 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 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:

  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:

  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 ^

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

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

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

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.

syntax highlighting: