Test::Most.3pm

Langue: en

Autres versions - même langue

Version: 2010-05-06 (fedora - 01/12/10)

Section: 3 (Bibliothèques de fonctions)

NAME

Test::Most - Most commonly needed test functions and features.

VERSION

Version 0.21

SYNOPSIS

This module provides you with the most commonly used testing functions and gives you a bit more fine-grained control over your test suite.
     use Test::Most tests => 4, 'die';
 
     ok 1, 'Normal calls to ok() should succeed';
     is 2, 2, '... as should all passing tests';
     eq_or_diff [3], [4], '... but failing tests should die';
     ok 4, '... will never get to here';
 
 

As you can see, the "eq_or_diff" test will fail. Because 'die' is in the import list, the test program will halt at that point.

EXPORT

All functions from the following modules will automatically be exported into your namespace:
*
"Test::More"
*
"Test::Exception"
*
"Test::Differences"
*
"Test::Deep"
*
"Test::Warn"

Functions which are optionally exported from any of those modules must be referred to by their fully-qualified name:

   Test::Deep::render_stack( $var, $stack );
 
 

FUNCTIONS

Several other functions are also automatically exported:

die_on_fail

  die_on_fail;
  is_deeply $foo, bar, '... we throw an exception if this fails';
 
 

This function, if called, will cause the test program to throw a Test::Most::Exception, effectively halting the test.

bail_on_fail

  bail_on_fail;
  is_deeply $foo, bar, '... we bail out if this fails';
 
 

This function, if called, will cause the test suite to BAIL_OUT() if any tests fail after it.

restore_fail

  die_on_fail;
  is_deeply $foo, bar, '... we throw an exception if this fails';
 
  restore_fail;
  cmp_bag(\@got, \@bag, '... we will not throw an exception if this fails';
 
 

This restores the original test failure behavior, so subsequent tests will no longer throw an exception or BAIL_OUT().

set_failure_handler

If you prefer other behavior to 'die_on_fail' or 'bail_on_fail', you can can set your own failure handler:
  set_failure_handler( sub {
      my $builder = shift;
      if ( $builder && $builder->{Test_Results}[-1] =~ /critical/ ) {
         send_admin_email("critical failure in tests");
      }
  } );
 
 

It receives the "Test::Builder" instance as its only argument.

Important: Note that if the failing test is the very last test run, then the $builder will likely be undefined. This is an unfortunate side effect of how "Test::Builder" has been designed.

explain

Similar to "diag()", but only outputs the message if $ENV{TEST_VERBOSE} is set. This is typically set by using the "-v" switch with "prove".

Unlike "diag()", any reference in the argument list is autumatically expanded using "Data::Dumper". Thus, instead of this:

  my $self = Some::Object->new($id);
  use Data::Dumper;
  explain 'I was just created', Dumper($self);
 
 

You can now just do this:

  my $self = Some::Object->new($id);
  explain 'I was just created:  ', $self;
 
 

That output will look similar to:

  I was just created: bless( {
    'id' => 2,
    'stack' => []
  }, 'Some::Object' )
 
 

Note that the ``dumpered'' output has the "Data::Dumper" variables $Indent, "Sortkeys" and "Terse" all set to the value of 1 (one). This allows for a much cleaner diagnostic output and at the present time cannot be overridden.

Requires "Test::Harness" 3.07 or greater.

show

Experimental. Just like "explain", but also tries to show you the lexical variable names:
  my $var   = 3;
  my @array = qw/ foo bar /;
  show $var, \@array;
  __END__
  $var = 3;
  @array = [
      'foo',
      'bar'
  ];
 
 

It will show $VAR1, $VAR2 ... $VAR_N for every variable it cannot figure out the variable name to:

  my @array = qw/ foo bar /;
  show @array;
  __END__
  $VAR1 = 'foo';
  $VAR2 = 'bar';
 
 

Note that this relies on Data::Dumper::Names version 0.03 or greater. If this is not present, it will warn and call explain instead. Also, it can only show the names for lexical variables. Globals such as %ENV or "%@" are not accessed via PadWalker and thus cannot be shown. It would be nice to find a workaround for this.

all_done

If the plan is specified as "defer_plan", you may call &all_done at the end of the test with an optional test number. This lets you set the plan without knowing the plan before you run the tests.

If you call it without a test number, the tests will still fail if you don't get to the end of the test. This is useful if you don't want to specify a plan but the tests exit unexpectedly. For example, the following would pass with "no_plan" but fails with "all_done".

  use Test::More 'defer_plan';
  ok 1;
  exit;
  ok 2;
  all_done;
 
 

See ``Deferred plans'' for more information.

DIE OR BAIL ON FAIL

Sometimes you want your test suite to throw an exception or BAIL_OUT() if a test fails. In order to provide maximum flexibility, there are three ways to accomplish each of these.

Import list

  use Test::Most 'die', tests => 7;
  use Test::Most qw< no_plan bail >;
 
 

If "die" or "bail" is anywhere in the import list, the test program/suite will throw a "Test::Most::Exception" or "BAIL_OUT()" as appropriate the first time a test fails. Calling "restore_fail" anywhere in the test program will restore the original behavior (not throwing an exception or bailing out).

Functions

  use Test::Most 'no_plan;
  ok $bar, 'The test suite will continue if this passes';
 
  die_on_fail;
  is_deeply $foo, bar, '... we throw an exception if this fails';
 
  restore_fail;
  ok $baz, 'The test suite will continue if this passes';
 
 

The "die_on_fail" and "bail_on_fail" functions will automatically set the desired behavior at runtime.

Deferred plans

  use Test::Most qw<defer_plan>;
  use My::Tests;
  my $test_count = My::Tests->run;
  all_done($test_count);
 
 

Sometimes it's difficult to know the plan up front, but you can calculate the plan as your tests run. As a result, you want to defer the plan until the end of the test. Typically, the best you can do is this:

  use Test::More 'no_plan';
  use My::Tests;
  My::Tests->run;
 
 

But when you do that, "Test::Builder" merely asserts that the number of tests you ran is the number of tests. Until now, there was no way of asserting that the number of tests you expected is the number of tests unless you do so before any tests have run. This fixes that problem.

Environment variables

  DIE_ON_FAIL=1 prove t/
  BAIL_ON_FAIL=1 prove t/
 
 

If the "DIE_ON_FAIL" or "BAIL_ON_FAIL" environment variables are true, any tests which use "Test::Most" will throw an exception or call BAIL_OUT on test failure.

RATIONALE

People want more control over their test suites. Sometimes when you see hundreds of tests failing and whizzing by, you want the test suite to simply halt on the first failure. This module gives you that control.

As for the reasons for the four test modules chosen, I ran code over a local copy of the CPAN to find the most commonly used testing modules. Here were the top ten (out of 287):

  Test::More              44461
  Test                     8937
  Test::Exception          1379
  Test::Simple              731
  Test::Base                316
  Test::Builder::Tester     193
  Test::NoWarnings          174
  Test::Differences         146
  Test::MockObject          139
  Test::Deep                127
 
 

The four modules chosen seemed the best fit for what "Test::Most" is trying to do. As of 0.02, we've added Test::Warn by request. It's not in the top ten, but it's a great and useful module.

AUTHOR

Curtis Poe, "<ovid at cpan.org>"

BUGS

Please report any bugs or feature requests to "bug-test-extended at rt.cpan.org", or through the web interface at http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Test-Most <http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Test-Most>. I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.

SUPPORT

You can find documentation for this module with the perldoc command.
     perldoc Test::Most
 
 

You can also look for information at:

*
RT: CPAN's request tracker

http://rt.cpan.org/NoAuth/Bugs.html?Dist=Test-Most <http://rt.cpan.org/NoAuth/Bugs.html?Dist=Test-Most>

*
AnnoCPAN: Annotated CPAN documentation

http://annocpan.org/dist/Test-Most <http://annocpan.org/dist/Test-Most>

*
CPAN Ratings

http://cpanratings.perl.org/d/Test-Most <http://cpanratings.perl.org/d/Test-Most>

*
Search CPAN

http://search.cpan.org/dist/Test-Most <http://search.cpan.org/dist/Test-Most>

TODO

Deferred plans

Sometimes you don't know the number of tests you will run when you use "Test::More". The "plan()" function allows you to delay specifying the plan, but you must still call it before the tests are run. This is an error:
  use Test::More;
 
  my $tests = 0;
  foreach my $test (
      my $count = run($test); # assumes tests are being run
      $tests += $count;
  }
  plan($tests);
 
 

The way around this is typically to use 'no_plan' and when the tests are done, "Test::Builder" merely sets the plan to the number of tests run. We'd like for the programmer to specify this number instead of letting "Test::Builder" do it. However, "Test::Builder" internals are a bit difficult to work with, so we're delaying this feature.

Cleaner skip()

  if ( $some_condition ) {
      skip $message, $num_tests;
  }
  else {
      # run those tests
  }
 
 

That would be cleaner and I might add it if enough people want it.

CAVEATS

Because of how Perl handles arguments, and because diagnostics are not really part of the Test Anything Protocol, what actually happens internally is that we note that a test has failed and we throw an exception or bail out as soon as the next test is called (but before it runs). This means that its arguments are automatically evaulated before we can take action:
  use Test::Most qw<no_plan die>;
 
  ok $foo, 'Die if this fails';
  ok factorial(123456),
    '... but wait a loooong time before you throw an exception';
 
 

ACKNOWLEDGEMENTS

Many thanks to "perl-qa" for arguing about this so much that I just went ahead and did it :)

Thanks to Aristotle for suggesting a better way to die or bailout.

Thanks to 'swillert' (<http://use.perl.org/~swillert/>) for suggesting a better implementation of my ``dumper explain'' idea (<http://use.perl.org/~Ovid/journal/37004>).

Copyright 2008 Curtis Poe, all rights reserved.

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.