1Test::More(3pm) Perl Programmers Reference Guide Test::More(3pm)
2
6 Test::More - yet another framework for writing test scripts
7
9 use Test::More tests => 23;
10 # or
11 use Test::More skip_all => $reason;
12 # or
13 use Test::More; # see done_testing()
14 BEGIN { use_ok( 'Some::Module' ); }
16 require_ok( 'Some::Module' );
17 # Various ways to say "ok"
19 ok($got eq $expected, $test_name);
20 is ($got, $expected, $test_name);
22 isnt($got, $expected, $test_name);
23 # Rather than print STDERR "# here's what went wrong\n"
25 diag("here's what went wrong");
26 like ($got, qr/expected/, $test_name);
28 unlike($got, qr/expected/, $test_name);
29 cmp_ok($got, '==', $expected, $test_name);
31 is_deeply($got_complex_structure, $expected_complex_structure, $test_name);
33 SKIP: {
35 skip $why, $how_many unless $have_some_feature;
36 ok( foo(), $test_name );
38 is( foo(42), 23, $test_name );
39 };
40 TODO: {
42 local $TODO = $why;
43 ok( foo(), $test_name );
45 is( foo(42), 23, $test_name );
46 };
47 can_ok($module, @methods);
49 isa_ok($object, $class);
50 pass($test_name);
52 fail($test_name);
53 BAIL_OUT($why);
55 # UNIMPLEMENTED!!!
57 my @status = Test::More::status;
58
60 STOP! If you're just getting started writing tests, have a look at
61 Test::Simple first. This is a drop in replacement for Test::Simple
62 which you can switch to once you get the hang of basic testing.
63 The purpose of this module is to provide a wide range of testing
65 utilities. Various ways to say "ok" with better diagnostics,
66 facilities to skip tests, test future features and compare complicated
67 data structures. While you can do almost anything with a simple "ok()"
68 function, it doesn't provide good diagnostic output.
69 I love it when a plan comes together
71 Before anything else, you need a testing plan. This basically declares
72 how many tests your script is going to run to protect against premature
73 failure.
74 The preferred way to do this is to declare a plan when you "use
76 Test::More".
77 use Test::More tests => 23;
79 There are cases when you will not know beforehand how many tests your
81 script is going to run. In this case, you can declare your tests at
82 the end.
83 use Test::More;
85 ... run your tests ...
87 done_testing( $number_of_tests_run );
89 Sometimes you really don't know how many tests were run, or it's too
91 difficult to calculate. In which case you can leave off
92 $number_of_tests_run.
93 In some cases, you'll want to completely skip an entire testing script.
95 use Test::More skip_all => $skip_reason;
97 Your script will declare a skip with the reason why you skipped and
99 exit immediately with a zero (success). See Test::Harness for details.
100 If you want to control what functions Test::More will export, you have
102 to use the 'import' option. For example, to import everything but
103 'fail', you'd do:
104 use Test::More tests => 23, import => ['!fail'];
106 Alternatively, you can use the plan() function. Useful for when you
108 have to calculate the number of tests.
109 use Test::More;
111 plan tests => keys %Stuff * 3;
112 or for deciding between running the tests at all:
114 use Test::More;
116 if( $^O eq 'MacOS' ) {
117 plan skip_all => 'Test irrelevant on MacOS';
118 }
119 else {
120 plan tests => 42;
121 }
122 done_testing
124 done_testing();
125 done_testing($number_of_tests);
126 If you don't know how many tests you're going to run, you can issue
128 the plan when you're done running tests.
129 $number_of_tests is the same as plan(), it's the number of tests
131 you expected to run. You can omit this, in which case the number
132 of tests you ran doesn't matter, just the fact that your tests ran
133 to conclusion.
134 This is safer than and replaces the "no_plan" plan.
136 Test names
138 By convention, each test is assigned a number in order. This is
139 largely done automatically for you. However, it's often very useful to
140 assign a name to each test. Which would you rather see:
141 ok 4
143 not ok 5
144 ok 6
145 or
147 ok 4 - basic multi-variable
149 not ok 5 - simple exponential
150 ok 6 - force == mass * acceleration
151 The later gives you some idea of what failed. It also makes it easier
153 to find the test in your script, simply search for "simple
154 exponential".
155 All test functions take a name argument. It's optional, but highly
157 suggested that you use it.
158 I'm ok, you're not ok.
160 The basic purpose of this module is to print out either "ok #" or "not
161 ok #" depending on if a given test succeeded or failed. Everything
162 else is just gravy.
163 All of the following print "ok" or "not ok" depending on if the test
165 succeeded or failed. They all also return true or false, respectively.
166 ok
168 ok($got eq $expected, $test_name);
169 This simply evaluates any expression ("$got eq $expected" is just a
171 simple example) and uses that to determine if the test succeeded or
172 failed. A true expression passes, a false one fails. Very simple.
173 For example:
175 ok( $exp{9} == 81, 'simple exponential' );
177 ok( Film->can('db_Main'), 'set_db()' );
178 ok( $p->tests == 4, 'saw tests' );
179 ok( !grep !defined $_, @items, 'items populated' );
180 (Mnemonic: "This is ok.")
182 $test_name is a very short description of the test that will be
184 printed out. It makes it very easy to find a test in your script
185 when it fails and gives others an idea of your intentions.
186 $test_name is optional, but we very strongly encourage its use.
187 Should an ok() fail, it will produce some diagnostics:
189 not ok 18 - sufficient mucus
191 # Failed test 'sufficient mucus'
192 # in foo.t at line 42.
193 This is the same as Test::Simple's ok() routine.
195 is
197 isnt
198 is ( $got, $expected, $test_name );
199 isnt( $got, $expected, $test_name );
200 Similar to ok(), is() and isnt() compare their two arguments with
202 "eq" and "ne" respectively and use the result of that to determine
203 if the test succeeded or failed. So these:
204 # Is the ultimate answer 42?
206 is( ultimate_answer(), 42, "Meaning of Life" );
207 # $foo isn't empty
209 isnt( $foo, '', "Got some foo" );
210 are similar to these:
212 ok( ultimate_answer() eq 42, "Meaning of Life" );
214 ok( $foo ne '', "Got some foo" );
215 (Mnemonic: "This is that." "This isn't that.")
217 So why use these? They produce better diagnostics on failure.
219 ok() cannot know what you are testing for (beyond the name), but
220 is() and isnt() know what the test was and why it failed. For
221 example this test:
222 my $foo = 'waffle'; my $bar = 'yarblokos';
224 is( $foo, $bar, 'Is foo the same as bar?' );
225 Will produce something like this:
227 not ok 17 - Is foo the same as bar?
229 # Failed test 'Is foo the same as bar?'
230 # in foo.t at line 139.
231 # got: 'waffle'
232 # expected: 'yarblokos'
233 So you can figure out what went wrong without rerunning the test.
235 You are encouraged to use is() and isnt() over ok() where possible,
237 however do not be tempted to use them to find out if something is
238 true or false!
239 # XXX BAD!
241 is( exists $brooklyn{tree}, 1, 'A tree grows in Brooklyn' );
242 This does not check if "exists $brooklyn{tree}" is true, it checks
244 if it returns 1. Very different. Similar caveats exist for false
245 and 0. In these cases, use ok().
246 ok( exists $brooklyn{tree}, 'A tree grows in Brooklyn' );
248 A simple call to isnt() usually does not provide a strong test but
250 there are cases when you cannot say much more about a value than
251 that it is different from some other value:
252 new_ok $obj, "Foo";
254 my $clone = $obj->clone;
256 isa_ok $obj, "Foo", "Foo->clone";
257 isnt $obj, $clone, "clone() produces a different object";
259 For those grammatical pedants out there, there's an "isn't()"
261 function which is an alias of isnt().
262 like
264 like( $got, qr/expected/, $test_name );
265 Similar to ok(), like() matches $got against the regex
267 "qr/expected/".
268 So this:
270 like($got, qr/expected/, 'this is like that');
272 is similar to:
274 ok( $got =~ /expected/, 'this is like that');
276 (Mnemonic "This is like that".)
278 The second argument is a regular expression. It may be given as a
280 regex reference (i.e. "qr//") or (for better compatibility with
281 older perls) as a string that looks like a regex (alternative
282 delimiters are currently not supported):
283 like( $got, '/expected/', 'this is like that' );
285 Regex options may be placed on the end ('/expected/i').
287 Its advantages over ok() are similar to that of is() and isnt().
289 Better diagnostics on failure.
290 unlike
292 unlike( $got, qr/expected/, $test_name );
293 Works exactly as like(), only it checks if $got does not match the
295 given pattern.
296 cmp_ok
298 cmp_ok( $got, $op, $expected, $test_name );
299 Halfway between ok() and is() lies cmp_ok(). This allows you to
301 compare two arguments using any binary perl operator.
302 # ok( $got eq $expected );
304 cmp_ok( $got, 'eq', $expected, 'this eq that' );
305 # ok( $got == $expected );
307 cmp_ok( $got, '==', $expected, 'this == that' );
308 # ok( $got && $expected );
310 cmp_ok( $got, '&&', $expected, 'this && that' );
311 ...etc...
312 Its advantage over ok() is when the test fails you'll know what
314 $got and $expected were:
315 not ok 1
317 # Failed test in foo.t at line 12.
318 # '23'
319 # &&
320 # undef
321 It's also useful in those cases where you are comparing numbers and
323 is()'s use of "eq" will interfere:
324 cmp_ok( $big_hairy_number, '==', $another_big_hairy_number );
326 It's especially useful when comparing greater-than or smaller-than
328 relation between values:
329 cmp_ok( $some_value, '<=', $upper_limit );
331 can_ok
333 can_ok($module, @methods);
334 can_ok($object, @methods);
335 Checks to make sure the $module or $object can do these @methods
337 (works with functions, too).
338 can_ok('Foo', qw(this that whatever));
340 is almost exactly like saying:
342 ok( Foo->can('this') &&
344 Foo->can('that') &&
345 Foo->can('whatever')
346 );
347 only without all the typing and with a better interface. Handy for
349 quickly testing an interface.
350 No matter how many @methods you check, a single can_ok() call
352 counts as one test. If you desire otherwise, use:
353 foreach my $meth (@methods) {
355 can_ok('Foo', $meth);
356 }
357 isa_ok
359 isa_ok($object, $class, $object_name);
360 isa_ok($subclass, $class, $object_name);
361 isa_ok($ref, $type, $ref_name);
362 Checks to see if the given "$object->isa($class)". Also checks to
364 make sure the object was defined in the first place. Handy for
365 this sort of thing:
366 my $obj = Some::Module->new;
368 isa_ok( $obj, 'Some::Module' );
369 where you'd otherwise have to write
371 my $obj = Some::Module->new;
373 ok( defined $obj && $obj->isa('Some::Module') );
374 to safeguard against your test script blowing up.
376 You can also test a class, to make sure that it has the right
378 ancestor:
379 isa_ok( 'Vole', 'Rodent' );
381 It works on references, too:
383 isa_ok( $array_ref, 'ARRAY' );
385 The diagnostics of this test normally just refer to 'the object'.
387 If you'd like them to be more specific, you can supply an
388 $object_name (for example 'Test customer').
389 new_ok
391 my $obj = new_ok( $class );
392 my $obj = new_ok( $class => \@args );
393 my $obj = new_ok( $class => \@args, $object_name );
394 A convenience function which combines creating an object and
396 calling isa_ok() on that object.
397 It is basically equivalent to:
399 my $obj = $class->new(@args);
401 isa_ok $obj, $class, $object_name;
402 If @args is not given, an empty list will be used.
404 This function only works on new() and it assumes new() will return
406 just a single object which isa $class.
407 pass
409 fail
410 pass($test_name);
411 fail($test_name);
412 Sometimes you just want to say that the tests have passed. Usually
414 the case is you've got some complicated condition that is difficult
415 to wedge into an ok(). In this case, you can simply use pass() (to
416 declare the test ok) or fail (for not ok). They are synonyms for
417 ok(1) and ok(0).
418 Use these very, very, very sparingly.
420 Module tests
422 You usually want to test if the module you're testing loads ok, rather
423 than just vomiting if its load fails. For such purposes we have
424 "use_ok" and "require_ok".
425 use_ok
427 BEGIN { use_ok($module); }
428 BEGIN { use_ok($module, @imports); }
429 These simply use the given $module and test to make sure the load
431 happened ok. It's recommended that you run use_ok() inside a BEGIN
432 block so its functions are exported at compile-time and prototypes
433 are properly honored.
434 If @imports are given, they are passed through to the use. So
436 this:
437 BEGIN { use_ok('Some::Module', qw(foo bar)) }
439 is like doing this:
441 use Some::Module qw(foo bar);
443 Version numbers can be checked like so:
445 # Just like "use Some::Module 1.02"
447 BEGIN { use_ok('Some::Module', 1.02) }
448 Don't try to do this:
450 BEGIN {
452 use_ok('Some::Module');
453 ...some code that depends on the use...
455 ...happening at compile time...
456 }
457 because the notion of "compile-time" is relative. Instead, you
459 want:
460 BEGIN { use_ok('Some::Module') }
462 BEGIN { ...some code that depends on the use... }
463 require_ok
465 require_ok($module);
466 require_ok($file);
467 Like use_ok(), except it requires the $module or $file.
469 Complex data structures
471 Not everything is a simple eq check or regex. There are times you need
472 to see if two data structures are equivalent. For these instances
473 Test::More provides a handful of useful functions.
474 NOTE I'm not quite sure what will happen with filehandles.
476 is_deeply
478 is_deeply( $got, $expected, $test_name );
479 Similar to is(), except that if $got and $expected are references,
481 it does a deep comparison walking each data structure to see if
482 they are equivalent. If the two structures are different, it will
483 display the place where they start differing.
484 is_deeply() compares the dereferenced values of references, the
486 references themselves (except for their type) are ignored. This
487 means aspects such as blessing and ties are not considered
488 "different".
489 is_deeply() currently has very limited handling of function
491 reference and globs. It merely checks if they have the same
492 referent. This may improve in the future.
493 Test::Differences and Test::Deep provide more in-depth
495 functionality along these lines.
496 Diagnostics
498 If you pick the right test function, you'll usually get a good idea of
499 what went wrong when it failed. But sometimes it doesn't work out that
500 way. So here we have ways for you to write your own diagnostic
501 messages which are safer than just "print STDERR".
502 diag
504 diag(@diagnostic_message);
505 Prints a diagnostic message which is guaranteed not to interfere
507 with test output. Like "print" @diagnostic_message is simply
508 concatenated together.
509 Returns false, so as to preserve failure.
511 Handy for this sort of thing:
513 ok( grep(/foo/, @users), "There's a foo user" ) or
515 diag("Since there's no foo, check that /etc/bar is set up right");
516 which would produce:
518 not ok 42 - There's a foo user
520 # Failed test 'There's a foo user'
521 # in foo.t at line 52.
522 # Since there's no foo, check that /etc/bar is set up right.
523 You might remember "ok() or diag()" with the mnemonic "open() or
525 die()".
526 NOTE The exact formatting of the diagnostic output is still
528 changing, but it is guaranteed that whatever you throw at it it
529 won't interfere with the test.
530 note
532 note(@diagnostic_message);
533 Like diag(), except the message will not be seen when the test is
535 run in a harness. It will only be visible in the verbose TAP
536 stream.
537 Handy for putting in notes which might be useful for debugging, but
539 don't indicate a problem.
540 note("Tempfile is $tempfile");
542 explain
544 my @dump = explain @diagnostic_message;
545 Will dump the contents of any references in a human readable
547 format. Usually you want to pass this into "note" or "diag".
548 Handy for things like...
550 is_deeply($have, $want) || diag explain $have;
552 or
554 note explain \%args;
556 Some::Class->method(%args);
557 Conditional tests
559 Sometimes running a test under certain conditions will cause the test
560 script to die. A certain function or method isn't implemented (such as
561 fork() on MacOS), some resource isn't available (like a net connection)
562 or a module isn't available. In these cases it's necessary to skip
563 tests, or declare that they are supposed to fail but will work in the
564 future (a todo test).
565 For more details on the mechanics of skip and todo tests see
567 Test::Harness.
568 The way Test::More handles this is with a named block. Basically, a
570 block of tests which can be skipped over or made todo. It's best if I
571 just show you...
572 SKIP: BLOCK
574 SKIP: {
575 skip $why, $how_many if $condition;
576 ...normal testing code goes here...
578 }
579 This declares a block of tests that might be skipped, $how_many
581 tests there are, $why and under what $condition to skip them. An
582 example is the easiest way to illustrate:
583 SKIP: {
585 eval { require HTML::Lint };
586 skip "HTML::Lint not installed", 2 if $@;
588 my $lint = new HTML::Lint;
590 isa_ok( $lint, "HTML::Lint" );
591 $lint->parse( $html );
593 is( $lint->errors, 0, "No errors found in HTML" );
594 }
595 If the user does not have HTML::Lint installed, the whole block of
597 code won't be run at all. Test::More will output special ok's
598 which Test::Harness interprets as skipped, but passing, tests.
599 It's important that $how_many accurately reflects the number of
601 tests in the SKIP block so the # of tests run will match up with
602 your plan. If your plan is "no_plan" $how_many is optional and
603 will default to 1.
604 It's perfectly safe to nest SKIP blocks. Each SKIP block must have
606 the label "SKIP", or Test::More can't work its magic.
607 You don't skip tests which are failing because there's a bug in
609 your program, or for which you don't yet have code written. For
610 that you use TODO. Read on.
611 TODO: BLOCK
613 TODO: {
614 local $TODO = $why if $condition;
615 ...normal testing code goes here...
617 }
618 Declares a block of tests you expect to fail and $why. Perhaps
620 it's because you haven't fixed a bug or haven't finished a new
621 feature:
622 TODO: {
624 local $TODO = "URI::Geller not finished";
625 my $card = "Eight of clubs";
627 is( URI::Geller->your_card, $card, 'Is THIS your card?' );
628 my $spoon;
630 URI::Geller->bend_spoon;
631 is( $spoon, 'bent', "Spoon bending, that's original" );
632 }
633 With a todo block, the tests inside are expected to fail.
635 Test::More will run the tests normally, but print out special flags
636 indicating they are "todo". Test::Harness will interpret failures
637 as being ok. Should anything succeed, it will report it as an
638 unexpected success. You then know the thing you had todo is done
639 and can remove the TODO flag.
640 The nice part about todo tests, as opposed to simply commenting out
642 a block of tests, is it's like having a programmatic todo list.
643 You know how much work is left to be done, you're aware of what
644 bugs there are, and you'll know immediately when they're fixed.
645 Once a todo test starts succeeding, simply move it outside the
647 block. When the block is empty, delete it.
648 NOTE: TODO tests require a Test::Harness upgrade else it will treat
650 it as a normal failure. See "CAVEATS and NOTES").
651 todo_skip
653 TODO: {
654 todo_skip $why, $how_many if $condition;
655 ...normal testing code...
657 }
658 With todo tests, it's best to have the tests actually run. That
660 way you'll know when they start passing. Sometimes this isn't
661 possible. Often a failing test will cause the whole program to die
662 or hang, even inside an "eval BLOCK" with and using "alarm". In
663 these extreme cases you have no choice but to skip over the broken
664 tests entirely.
665 The syntax and behavior is similar to a "SKIP: BLOCK" except the
667 tests will be marked as failing but todo. Test::Harness will
668 interpret them as passing.
669 When do I use SKIP vs. TODO?
671 If it's something the user might not be able to do, use SKIP. This
672 includes optional modules that aren't installed, running under an
673 OS that doesn't have some feature (like fork() or symlinks), or
674 maybe you need an Internet connection and one isn't available.
675 If it's something the programmer hasn't done yet, use TODO. This
677 is for any code you haven't written yet, or bugs you have yet to
678 fix, but want to put tests in your testing script (always a good
679 idea).
680 Test control
682 BAIL_OUT
683 BAIL_OUT($reason);
684 Indicates to the harness that things are going so badly all testing
686 should terminate. This includes the running any additional test
687 scripts.
688 This is typically used when testing cannot continue such as a
690 critical module failing to compile or a necessary external utility
691 not being available such as a database connection failing.
692 The test will exit with 255.
694 For even better control look at Test::Most.
696 Discouraged comparison functions
698 The use of the following functions is discouraged as they are not
699 actually testing functions and produce no diagnostics to help figure
700 out what went wrong. They were written before is_deeply() existed
701 because I couldn't figure out how to display a useful diff of two
702 arbitrary data structures.
703 These functions are usually used inside an ok().
705 ok( eq_array(\@got, \@expected) );
707 "is_deeply()" can do that better and with diagnostics.
709 is_deeply( \@got, \@expected );
711 They may be deprecated in future versions.
713 eq_array
715 my $is_eq = eq_array(\@got, \@expected);
716 Checks if two arrays are equivalent. This is a deep check, so
718 multi-level structures are handled correctly.
719 eq_hash
721 my $is_eq = eq_hash(\%got, \%expected);
722 Determines if the two hashes contain the same keys and values.
724 This is a deep check.
725 eq_set
727 my $is_eq = eq_set(\@got, \@expected);
728 Similar to eq_array(), except the order of the elements is not
730 important. This is a deep check, but the irrelevancy of order only
731 applies to the top level.
732 ok( eq_set(\@got, \@expected) );
734 Is better written:
736 is_deeply( [sort @got], [sort @expected] );
738 NOTE By historical accident, this is not a true set comparison.
740 While the order of elements does not matter, duplicate elements do.
741 NOTE eq_set() does not know how to deal with references at the top
743 level. The following is an example of a comparison which might not
744 work:
745 eq_set([\1, \2], [\2, \1]);
747 Test::Deep contains much better set comparison functions.
749 Extending and Embedding Test::More
751 Sometimes the Test::More interface isn't quite enough. Fortunately,
752 Test::More is built on top of Test::Builder which provides a single,
753 unified backend for any test library to use. This means two test
754 libraries which both use Test::Builder can be used together in the same
755 program.
756 If you simply want to do a little tweaking of how the tests behave, you
758 can access the underlying Test::Builder object like so:
759 builder
761 my $test_builder = Test::More->builder;
762 Returns the Test::Builder object underlying Test::More for you to
764 play with.
765
767 If all your tests passed, Test::Builder will exit with zero (which is
768 normal). If anything failed it will exit with how many failed. If you
769 run less (or more) tests than you planned, the missing (or extras) will
770 be considered failures. If no tests were ever run Test::Builder will
771 throw a warning and exit with 255. If the test died, even after having
772 successfully completed all its tests, it will still be considered a
773 failure and will exit with 255.
774 So the exit codes are...
776 0 all tests successful
778 255 test died or all passed but wrong # of tests run
779 any other number how many failed (including missing or extras)
780 If you fail more than 254 tests, it will be reported as 254.
782 NOTE This behavior may go away in future versions.
784
786 Backwards compatibility
787 Test::More works with Perls as old as 5.6.0.
788 utf8 / "Wide character in print"
790 If you use utf8 or other non-ASCII characters with Test::More you
791 might get a "Wide character in print" warning. Using "binmode
792 STDOUT, ":utf8"" will not fix it. Test::Builder (which powers
793 Test::More) duplicates STDOUT and STDERR. So any changes to them,
794 including changing their output disciplines, will not be seem by
795 Test::More.
796 The work around is to change the filehandles used by Test::Builder
798 directly.
799 my $builder = Test::More->builder;
801 binmode $builder->output, ":utf8";
802 binmode $builder->failure_output, ":utf8";
803 binmode $builder->todo_output, ":utf8";
804 Overloaded objects
806 String overloaded objects are compared as strings (or in cmp_ok()'s
807 case, strings or numbers as appropriate to the comparison op).
808 This prevents Test::More from piercing an object's interface
809 allowing better blackbox testing. So if a function starts
810 returning overloaded objects instead of bare strings your tests
811 won't notice the difference. This is good.
812 However, it does mean that functions like is_deeply() cannot be
814 used to test the internals of string overloaded objects. In this
815 case I would suggest Test::Deep which contains more flexible
816 testing functions for complex data structures.
817 Threads
819 Test::More will only be aware of threads if "use threads" has been
820 done before Test::More is loaded. This is ok:
821 use threads;
823 use Test::More;
824 This may cause problems:
826 use Test::More
828 use threads;
829 5.8.1 and above are supported. Anything below that has too many
831 bugs.
832 Test::Harness upgrade
834 no_plan, todo and done_testing() depend on new Test::Harness
835 features and fixes. If you're going to distribute tests that use
836 no_plan or todo your end-users will have to upgrade Test::Harness
837 to the latest one on CPAN. If you avoid no_plan and TODO tests,
838 the stock Test::Harness will work fine.
839 Installing Test::More should also upgrade Test::Harness.
841
843 This is a case of convergent evolution with Joshua Pritikin's Test
844 module. I was largely unaware of its existence when I'd first written
845 my own ok() routines. This module exists because I can't figure out
846 how to easily wedge test names into Test's interface (along with a few
847 other problems).
848 The goal here is to have a testing utility that's simple to learn,
850 quick to use and difficult to trip yourself up with while still
851 providing more flexibility than the existing Test.pm. As such, the
852 names of the most common routines are kept tiny, special cases and
853 magic side-effects are kept to a minimum. WYSIWYG.
854
856 Test::Simple if all this confuses you and you just want to write some
857 tests. You can upgrade to Test::More later (it's forward compatible).
858 Test::Harness is the test runner and output interpreter for Perl. It's
860 the thing that powers "make test" and where the "prove" utility comes
861 from.
862 Test::Legacy tests written with Test.pm, the original testing module,
864 do not play well with other testing libraries. Test::Legacy emulates
865 the Test.pm interface and does play well with others.
866 Test::Differences for more ways to test complex data structures. And
868 it plays well with Test::More.
869 Test::Class is like xUnit but more perlish.
871 Test::Deep gives you more powerful complex data structure testing.
873 Test::Inline shows the idea of embedded testing.
875 Bundle::Test installs a whole bunch of useful test modules.
877
879 Michael G Schwern <schwern@pobox.com> with much inspiration from Joshua
880 Pritikin's Test module and lots of help from Barrie Slaymaker, Tony
881 Bowden, blackstar.co.uk, chromatic, Fergal Daly and the perl-qa gang.
882
884 See http://rt.cpan.org to report and view bugs.
885
887 The source code repository for Test::More can be found at
888 http://github.com/schwern/test-more/.
889
891 Copyright 2001-2008 by Michael G Schwern <schwern@pobox.com>.
892 This program is free software; you can redistribute it and/or modify it
894 under the same terms as Perl itself.
895 See http://www.perl.com/perl/misc/Artistic.html
897perl v5.10.1 2009-07-07 Test::More(3pm)