Test(3)

Index for
Section 3
Alphabetical
listing for T
Bottom of
page
Test(3)
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
      comparison.

      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
  · NORMAL TESTS
      These tests are expected to succeed.  If they don't something's screwed
      up!

  · 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 argument, skip works exactly
      the same way as do normal tests.

  · TODO TESTS
      TODO tests are designed for maintaining an executable TODO list.	These
      tests are expected NOT to succeed.  If a TODO test does succeed, 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 normal 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 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".  (The file, line, and test
  number are not included because their correspondence 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 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
  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.
Index for
Section 3
Alphabetical
listing for T
Top of
page