summaryrefslogtreecommitdiffstats
path: root/upstream/mageia-cauldron/man3pm/Test::More.3pm
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-15 19:43:11 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-15 19:43:11 +0000
commitfc22b3d6507c6745911b9dfcc68f1e665ae13dbc (patch)
treece1e3bce06471410239a6f41282e328770aa404a /upstream/mageia-cauldron/man3pm/Test::More.3pm
parentInitial commit. (diff)
downloadmanpages-l10n-fc22b3d6507c6745911b9dfcc68f1e665ae13dbc.tar.xz
manpages-l10n-fc22b3d6507c6745911b9dfcc68f1e665ae13dbc.zip
Adding upstream version 4.22.0.upstream/4.22.0
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'upstream/mageia-cauldron/man3pm/Test::More.3pm')
-rw-r--r--upstream/mageia-cauldron/man3pm/Test::More.3pm1319
1 files changed, 1319 insertions, 0 deletions
diff --git a/upstream/mageia-cauldron/man3pm/Test::More.3pm b/upstream/mageia-cauldron/man3pm/Test::More.3pm
new file mode 100644
index 00000000..9ab72c6f
--- /dev/null
+++ b/upstream/mageia-cauldron/man3pm/Test::More.3pm
@@ -0,0 +1,1319 @@
+.\" -*- mode: troff; coding: utf-8 -*-
+.\" Automatically generated by Pod::Man 5.01 (Pod::Simple 3.43)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
+.ie n \{\
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds C`
+. ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is >0, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{\
+. if \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. if !\nF==2 \{\
+. nr % 0
+. nr F 2
+. \}
+. \}
+.\}
+.rr rF
+.\" ========================================================================
+.\"
+.IX Title "Test::More 3pm"
+.TH Test::More 3pm 2023-11-28 "perl v5.38.2" "Perl Programmers Reference Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH NAME
+Test::More \- yet another framework for writing test scripts
+.SH SYNOPSIS
+.IX Header "SYNOPSIS"
+.Vb 5
+\& use Test::More tests => 23;
+\& # or
+\& use Test::More skip_all => $reason;
+\& # or
+\& use Test::More; # see done_testing()
+\&
+\& require_ok( \*(AqSome::Module\*(Aq );
+\&
+\& # Various ways to say "ok"
+\& ok($got eq $expected, $test_name);
+\&
+\& is ($got, $expected, $test_name);
+\& isnt($got, $expected, $test_name);
+\&
+\& # Rather than print STDERR "# here\*(Aqs what went wrong\en"
+\& diag("here\*(Aqs what went wrong");
+\&
+\& like ($got, qr/expected/, $test_name);
+\& unlike($got, qr/expected/, $test_name);
+\&
+\& cmp_ok($got, \*(Aq==\*(Aq, $expected, $test_name);
+\&
+\& is_deeply($got_complex_structure, $expected_complex_structure, $test_name);
+\&
+\& SKIP: {
+\& skip $why, $how_many unless $have_some_feature;
+\&
+\& ok( foo(), $test_name );
+\& is( foo(42), 23, $test_name );
+\& };
+\&
+\& TODO: {
+\& local $TODO = $why;
+\&
+\& ok( foo(), $test_name );
+\& is( foo(42), 23, $test_name );
+\& };
+\&
+\& can_ok($module, @methods);
+\& isa_ok($object, $class);
+\&
+\& pass($test_name);
+\& fail($test_name);
+\&
+\& BAIL_OUT($why);
+\&
+\& # UNIMPLEMENTED!!!
+\& my @status = Test::More::status;
+.Ve
+.SH DESCRIPTION
+.IX Header "DESCRIPTION"
+\&\fBSTOP!\fR If you're just getting started writing tests, have a look at
+Test2::Suite first.
+.PP
+This is a drop in replacement for Test::Simple which you can switch to once you
+get the hang of basic testing.
+.PP
+The purpose of this module is to provide a wide range of testing
+utilities. Various ways to say "ok" with better diagnostics,
+facilities to skip tests, test future features and compare complicated
+data structures. While you can do almost anything with a simple
+\&\f(CWok()\fR function, it doesn't provide good diagnostic output.
+.SS "I love it when a plan comes together"
+.IX Subsection "I love it when a plan comes together"
+Before anything else, you need a testing plan. This basically declares
+how many tests your script is going to run to protect against premature
+failure.
+.PP
+The preferred way to do this is to declare a plan when you \f(CW\*(C`use Test::More\*(C'\fR.
+.PP
+.Vb 1
+\& use Test::More tests => 23;
+.Ve
+.PP
+There are cases when you will not know beforehand how many tests your
+script is going to run. In this case, you can declare your tests at
+the end.
+.PP
+.Vb 1
+\& use Test::More;
+\&
+\& ... run your tests ...
+\&
+\& done_testing( $number_of_tests_run );
+.Ve
+.PP
+\&\fBNOTE\fR \f(CWdone_testing()\fR should never be called in an \f(CW\*(C`END { ... }\*(C'\fR block.
+.PP
+Sometimes you really don't know how many tests were run, or it's too
+difficult to calculate. In which case you can leave off
+\&\f(CW$number_of_tests_run\fR.
+.PP
+In some cases, you'll want to completely skip an entire testing script.
+.PP
+.Vb 1
+\& use Test::More skip_all => $skip_reason;
+.Ve
+.PP
+Your script will declare a skip with the reason why you skipped and
+exit immediately with a zero (success). See Test::Harness for
+details.
+.PP
+If you want to control what functions Test::More will export, you
+have to use the 'import' option. For example, to import everything
+but 'fail', you'd do:
+.PP
+.Vb 1
+\& use Test::More tests => 23, import => [\*(Aq!fail\*(Aq];
+.Ve
+.PP
+Alternatively, you can use the \f(CWplan()\fR function. Useful for when you
+have to calculate the number of tests.
+.PP
+.Vb 2
+\& use Test::More;
+\& plan tests => keys %Stuff * 3;
+.Ve
+.PP
+or for deciding between running the tests at all:
+.PP
+.Vb 7
+\& use Test::More;
+\& if( $^O eq \*(AqMacOS\*(Aq ) {
+\& plan skip_all => \*(AqTest irrelevant on MacOS\*(Aq;
+\& }
+\& else {
+\& plan tests => 42;
+\& }
+.Ve
+.IP \fBdone_testing\fR 4
+.IX Item "done_testing"
+.Vb 2
+\& done_testing();
+\& done_testing($number_of_tests);
+.Ve
+.Sp
+If you don't know how many tests you're going to run, you can issue
+the plan when you're done running tests.
+.Sp
+\&\f(CW$number_of_tests\fR is the same as \f(CWplan()\fR, it's the number of tests you
+expected to run. You can omit this, in which case the number of tests
+you ran doesn't matter, just the fact that your tests ran to
+conclusion.
+.Sp
+This is safer than and replaces the "no_plan" plan.
+.Sp
+\&\fBNote:\fR You must never put \f(CWdone_testing()\fR inside an \f(CW\*(C`END { ... }\*(C'\fR block.
+The plan is there to ensure your test does not exit before testing has
+completed. If you use an END block you completely bypass this protection.
+.SS "Test names"
+.IX Subsection "Test names"
+By convention, each test is assigned a number in order. This is
+largely done automatically for you. However, it's often very useful to
+assign a name to each test. Which would you rather see:
+.PP
+.Vb 3
+\& ok 4
+\& not ok 5
+\& ok 6
+.Ve
+.PP
+or
+.PP
+.Vb 3
+\& ok 4 \- basic multi\-variable
+\& not ok 5 \- simple exponential
+\& ok 6 \- force == mass * acceleration
+.Ve
+.PP
+The later gives you some idea of what failed. It also makes it easier
+to find the test in your script, simply search for "simple
+exponential".
+.PP
+All test functions take a name argument. It's optional, but highly
+suggested that you use it.
+.SS "I'm ok, you're not ok."
+.IX Subsection "I'm ok, you're not ok."
+The basic purpose of this module is to print out either "ok #" or "not
+ok #" depending on if a given test succeeded or failed. Everything
+else is just gravy.
+.PP
+All of the following print "ok" or "not ok" depending on if the test
+succeeded or failed. They all also return true or false,
+respectively.
+.IP \fBok\fR 4
+.IX Item "ok"
+.Vb 1
+\& ok($got eq $expected, $test_name);
+.Ve
+.Sp
+This simply evaluates any expression (\f(CW\*(C`$got eq $expected\*(C'\fR is just a
+simple example) and uses that to determine if the test succeeded or
+failed. A true expression passes, a false one fails. Very simple.
+.Sp
+For example:
+.Sp
+.Vb 4
+\& ok( $exp{9} == 81, \*(Aqsimple exponential\*(Aq );
+\& ok( Film\->can(\*(Aqdb_Main\*(Aq), \*(Aqset_db()\*(Aq );
+\& ok( $p\->tests == 4, \*(Aqsaw tests\*(Aq );
+\& ok( !grep(!defined $_, @items), \*(Aqall items defined\*(Aq );
+.Ve
+.Sp
+(Mnemonic: "This is ok.")
+.Sp
+\&\f(CW$test_name\fR is a very short description of the test that will be printed
+out. It makes it very easy to find a test in your script when it fails
+and gives others an idea of your intentions. \f(CW$test_name\fR is optional,
+but we \fBvery\fR strongly encourage its use.
+.Sp
+Should an \f(CWok()\fR fail, it will produce some diagnostics:
+.Sp
+.Vb 3
+\& not ok 18 \- sufficient mucus
+\& # Failed test \*(Aqsufficient mucus\*(Aq
+\& # in foo.t at line 42.
+.Ve
+.Sp
+This is the same as Test::Simple's \f(CWok()\fR routine.
+.IP \fBis\fR 4
+.IX Item "is"
+.PD 0
+.IP \fBisnt\fR 4
+.IX Item "isnt"
+.PD
+.Vb 2
+\& is ( $got, $expected, $test_name );
+\& isnt( $got, $expected, $test_name );
+.Ve
+.Sp
+Similar to \f(CWok()\fR, \f(CWis()\fR and \f(CWisnt()\fR compare their two arguments
+with \f(CW\*(C`eq\*(C'\fR and \f(CW\*(C`ne\*(C'\fR respectively and use the result of that to
+determine if the test succeeded or failed. So these:
+.Sp
+.Vb 2
+\& # Is the ultimate answer 42?
+\& is( ultimate_answer(), 42, "Meaning of Life" );
+\&
+\& # $foo isn\*(Aqt empty
+\& isnt( $foo, \*(Aq\*(Aq, "Got some foo" );
+.Ve
+.Sp
+are similar to these:
+.Sp
+.Vb 2
+\& ok( ultimate_answer() eq 42, "Meaning of Life" );
+\& ok( $foo ne \*(Aq\*(Aq, "Got some foo" );
+.Ve
+.Sp
+\&\f(CW\*(C`undef\*(C'\fR will only ever match \f(CW\*(C`undef\*(C'\fR. So you can test a value
+against \f(CW\*(C`undef\*(C'\fR like this:
+.Sp
+.Vb 1
+\& is($not_defined, undef, "undefined as expected");
+.Ve
+.Sp
+(Mnemonic: "This is that." "This isn't that.")
+.Sp
+So why use these? They produce better diagnostics on failure. \f(CWok()\fR
+cannot know what you are testing for (beyond the name), but \f(CWis()\fR and
+\&\f(CWisnt()\fR know what the test was and why it failed. For example this
+test:
+.Sp
+.Vb 2
+\& my $foo = \*(Aqwaffle\*(Aq; my $bar = \*(Aqyarblokos\*(Aq;
+\& is( $foo, $bar, \*(AqIs foo the same as bar?\*(Aq );
+.Ve
+.Sp
+Will produce something like this:
+.Sp
+.Vb 5
+\& not ok 17 \- Is foo the same as bar?
+\& # Failed test \*(AqIs foo the same as bar?\*(Aq
+\& # in foo.t at line 139.
+\& # got: \*(Aqwaffle\*(Aq
+\& # expected: \*(Aqyarblokos\*(Aq
+.Ve
+.Sp
+So you can figure out what went wrong without rerunning the test.
+.Sp
+You are encouraged to use \f(CWis()\fR and \f(CWisnt()\fR over \f(CWok()\fR where possible,
+however do not be tempted to use them to find out if something is
+true or false!
+.Sp
+.Vb 2
+\& # XXX BAD!
+\& is( exists $brooklyn{tree}, 1, \*(AqA tree grows in Brooklyn\*(Aq );
+.Ve
+.Sp
+This does not check if \f(CW\*(C`exists $brooklyn{tree}\*(C'\fR is true, it checks if
+it returns 1. Very different. Similar caveats exist for false and 0.
+In these cases, use \f(CWok()\fR.
+.Sp
+.Vb 1
+\& ok( exists $brooklyn{tree}, \*(AqA tree grows in Brooklyn\*(Aq );
+.Ve
+.Sp
+A simple call to \f(CWisnt()\fR usually does not provide a strong test but there
+are cases when you cannot say much more about a value than that it is
+different from some other value:
+.Sp
+.Vb 1
+\& new_ok $obj, "Foo";
+\&
+\& my $clone = $obj\->clone;
+\& isa_ok $obj, "Foo", "Foo\->clone";
+\&
+\& isnt $obj, $clone, "clone() produces a different object";
+.Ve
+.Sp
+Historically we supported an \f(CW\*(C`isn\*(Aqt()\*(C'\fR function as an alias of
+\&\f(CWisnt()\fR, however in Perl 5.37.9 support for the use of aprostrophe as
+a package separator was deprecated and by Perl 5.42.0 support for it
+will have been removed completely. Accordingly use of \f(CW\*(C`isn\*(Aqt()\*(C'\fR is also
+deprecated, and will produce warnings when used unless 'deprecated'
+warnings are specifically disabled in the scope where it is used. You
+are strongly advised to migrate to using \f(CWisnt()\fR instead.
+.IP \fBlike\fR 4
+.IX Item "like"
+.Vb 1
+\& like( $got, qr/expected/, $test_name );
+.Ve
+.Sp
+Similar to \f(CWok()\fR, \f(CWlike()\fR matches \f(CW$got\fR against the regex \f(CW\*(C`qr/expected/\*(C'\fR.
+.Sp
+So this:
+.Sp
+.Vb 1
+\& like($got, qr/expected/, \*(Aqthis is like that\*(Aq);
+.Ve
+.Sp
+is similar to:
+.Sp
+.Vb 1
+\& ok( $got =~ m/expected/, \*(Aqthis is like that\*(Aq);
+.Ve
+.Sp
+(Mnemonic "This is like that".)
+.Sp
+The second argument is a regular expression. It may be given as a
+regex reference (i.e. \f(CW\*(C`qr//\*(C'\fR) or (for better compatibility with older
+perls) as a string that looks like a regex (alternative delimiters are
+currently not supported):
+.Sp
+.Vb 1
+\& like( $got, \*(Aq/expected/\*(Aq, \*(Aqthis is like that\*(Aq );
+.Ve
+.Sp
+Regex options may be placed on the end (\f(CW\*(Aq/expected/i\*(Aq\fR).
+.Sp
+Its advantages over \f(CWok()\fR are similar to that of \f(CWis()\fR and \f(CWisnt()\fR. Better
+diagnostics on failure.
+.IP \fBunlike\fR 4
+.IX Item "unlike"
+.Vb 1
+\& unlike( $got, qr/expected/, $test_name );
+.Ve
+.Sp
+Works exactly as \f(CWlike()\fR, only it checks if \f(CW$got\fR \fBdoes not\fR match the
+given pattern.
+.IP \fBcmp_ok\fR 4
+.IX Item "cmp_ok"
+.Vb 1
+\& cmp_ok( $got, $op, $expected, $test_name );
+.Ve
+.Sp
+Halfway between \f(CWok()\fR and \f(CWis()\fR lies \f(CWcmp_ok()\fR. This allows you
+to compare two arguments using any binary perl operator. The test
+passes if the comparison is true and fails otherwise.
+.Sp
+.Vb 2
+\& # ok( $got eq $expected );
+\& cmp_ok( $got, \*(Aqeq\*(Aq, $expected, \*(Aqthis eq that\*(Aq );
+\&
+\& # ok( $got == $expected );
+\& cmp_ok( $got, \*(Aq==\*(Aq, $expected, \*(Aqthis == that\*(Aq );
+\&
+\& # ok( $got && $expected );
+\& cmp_ok( $got, \*(Aq&&\*(Aq, $expected, \*(Aqthis && that\*(Aq );
+\& ...etc...
+.Ve
+.Sp
+Its advantage over \f(CWok()\fR is when the test fails you'll know what \f(CW$got\fR
+and \f(CW$expected\fR were:
+.Sp
+.Vb 5
+\& not ok 1
+\& # Failed test in foo.t at line 12.
+\& # \*(Aq23\*(Aq
+\& # &&
+\& # undef
+.Ve
+.Sp
+It's also useful in those cases where you are comparing numbers and
+\&\f(CWis()\fR's use of \f(CW\*(C`eq\*(C'\fR will interfere:
+.Sp
+.Vb 1
+\& cmp_ok( $big_hairy_number, \*(Aq==\*(Aq, $another_big_hairy_number );
+.Ve
+.Sp
+It's especially useful when comparing greater-than or smaller-than
+relation between values:
+.Sp
+.Vb 1
+\& cmp_ok( $some_value, \*(Aq<=\*(Aq, $upper_limit );
+.Ve
+.IP \fBcan_ok\fR 4
+.IX Item "can_ok"
+.Vb 2
+\& can_ok($module, @methods);
+\& can_ok($object, @methods);
+.Ve
+.Sp
+Checks to make sure the \f(CW$module\fR or \f(CW$object\fR can do these \f(CW@methods\fR
+(works with functions, too).
+.Sp
+.Vb 1
+\& can_ok(\*(AqFoo\*(Aq, qw(this that whatever));
+.Ve
+.Sp
+is almost exactly like saying:
+.Sp
+.Vb 4
+\& ok( Foo\->can(\*(Aqthis\*(Aq) &&
+\& Foo\->can(\*(Aqthat\*(Aq) &&
+\& Foo\->can(\*(Aqwhatever\*(Aq)
+\& );
+.Ve
+.Sp
+only without all the typing and with a better interface. Handy for
+quickly testing an interface.
+.Sp
+No matter how many \f(CW@methods\fR you check, a single \f(CWcan_ok()\fR call counts
+as one test. If you desire otherwise, use:
+.Sp
+.Vb 3
+\& foreach my $meth (@methods) {
+\& can_ok(\*(AqFoo\*(Aq, $meth);
+\& }
+.Ve
+.IP \fBisa_ok\fR 4
+.IX Item "isa_ok"
+.Vb 3
+\& isa_ok($object, $class, $object_name);
+\& isa_ok($subclass, $class, $object_name);
+\& isa_ok($ref, $type, $ref_name);
+.Ve
+.Sp
+Checks to see if the given \f(CW\*(C`$object\->isa($class)\*(C'\fR. Also checks to make
+sure the object was defined in the first place. Handy for this sort
+of thing:
+.Sp
+.Vb 2
+\& my $obj = Some::Module\->new;
+\& isa_ok( $obj, \*(AqSome::Module\*(Aq );
+.Ve
+.Sp
+where you'd otherwise have to write
+.Sp
+.Vb 2
+\& my $obj = Some::Module\->new;
+\& ok( defined $obj && $obj\->isa(\*(AqSome::Module\*(Aq) );
+.Ve
+.Sp
+to safeguard against your test script blowing up.
+.Sp
+You can also test a class, to make sure that it has the right ancestor:
+.Sp
+.Vb 1
+\& isa_ok( \*(AqVole\*(Aq, \*(AqRodent\*(Aq );
+.Ve
+.Sp
+It works on references, too:
+.Sp
+.Vb 1
+\& isa_ok( $array_ref, \*(AqARRAY\*(Aq );
+.Ve
+.Sp
+The diagnostics of this test normally just refer to 'the object'. If
+you'd like them to be more specific, you can supply an \f(CW$object_name\fR
+(for example 'Test customer').
+.IP \fBnew_ok\fR 4
+.IX Item "new_ok"
+.Vb 3
+\& my $obj = new_ok( $class );
+\& my $obj = new_ok( $class => \e@args );
+\& my $obj = new_ok( $class => \e@args, $object_name );
+.Ve
+.Sp
+A convenience function which combines creating an object and calling
+\&\f(CWisa_ok()\fR on that object.
+.Sp
+It is basically equivalent to:
+.Sp
+.Vb 2
+\& my $obj = $class\->new(@args);
+\& isa_ok $obj, $class, $object_name;
+.Ve
+.Sp
+If \f(CW@args\fR is not given, an empty list will be used.
+.Sp
+This function only works on \f(CWnew()\fR and it assumes \f(CWnew()\fR will return
+just a single object which isa \f(CW$class\fR.
+.IP \fBsubtest\fR 4
+.IX Item "subtest"
+.Vb 1
+\& subtest $name => \e&code, @args;
+.Ve
+.Sp
+\&\f(CWsubtest()\fR runs the &code as its own little test with its own plan and
+its own result. The main test counts this as a single test using the
+result of the whole subtest to determine if its ok or not ok.
+.Sp
+For example...
+.Sp
+.Vb 1
+\& use Test::More tests => 3;
+\&
+\& pass("First test");
+\&
+\& subtest \*(AqAn example subtest\*(Aq => sub {
+\& plan tests => 2;
+\&
+\& pass("This is a subtest");
+\& pass("So is this");
+\& };
+\&
+\& pass("Third test");
+.Ve
+.Sp
+This would produce.
+.Sp
+.Vb 8
+\& 1..3
+\& ok 1 \- First test
+\& # Subtest: An example subtest
+\& 1..2
+\& ok 1 \- This is a subtest
+\& ok 2 \- So is this
+\& ok 2 \- An example subtest
+\& ok 3 \- Third test
+.Ve
+.Sp
+A subtest may call \f(CW\*(C`skip_all\*(C'\fR. No tests will be run, but the subtest is
+considered a skip.
+.Sp
+.Vb 4
+\& subtest \*(Aqskippy\*(Aq => sub {
+\& plan skip_all => \*(Aqcuz I said so\*(Aq;
+\& pass(\*(Aqthis test will never be run\*(Aq);
+\& };
+.Ve
+.Sp
+Returns true if the subtest passed, false otherwise.
+.Sp
+Due to how subtests work, you may omit a plan if you desire. This adds an
+implicit \f(CWdone_testing()\fR to the end of your subtest. The following two
+subtests are equivalent:
+.Sp
+.Vb 5
+\& subtest \*(Aqsubtest with implicit done_testing()\*(Aq, sub {
+\& ok 1, \*(Aqsubtests with an implicit done testing should work\*(Aq;
+\& ok 1, \*(Aq... and support more than one test\*(Aq;
+\& ok 1, \*(Aq... no matter how many tests are run\*(Aq;
+\& };
+\&
+\& subtest \*(Aqsubtest with explicit done_testing()\*(Aq, sub {
+\& ok 1, \*(Aqsubtests with an explicit done testing should work\*(Aq;
+\& ok 1, \*(Aq... and support more than one test\*(Aq;
+\& ok 1, \*(Aq... no matter how many tests are run\*(Aq;
+\& done_testing();
+\& };
+.Ve
+.Sp
+Extra arguments given to \f(CW\*(C`subtest\*(C'\fR are passed to the callback. For example:
+.Sp
+.Vb 4
+\& sub my_subtest {
+\& my $range = shift;
+\& ...
+\& }
+\&
+\& for my $range (1, 10, 100, 1000) {
+\& subtest "testing range $range", \e&my_subtest, $range;
+\& }
+.Ve
+.IP \fBpass\fR 4
+.IX Item "pass"
+.PD 0
+.IP \fBfail\fR 4
+.IX Item "fail"
+.PD
+.Vb 2
+\& pass($test_name);
+\& fail($test_name);
+.Ve
+.Sp
+Sometimes you just want to say that the tests have passed. Usually
+the case is you've got some complicated condition that is difficult to
+wedge into an \f(CWok()\fR. In this case, you can simply use \f(CWpass()\fR (to
+declare the test ok) or fail (for not ok). They are synonyms for
+\&\f(CWok(1)\fR and \f(CWok(0)\fR.
+.Sp
+Use these very, very, very sparingly.
+.SS "Module tests"
+.IX Subsection "Module tests"
+Sometimes you want to test if a module, or a list of modules, can
+successfully load. For example, you'll often want a first test which
+simply loads all the modules in the distribution to make sure they
+work before going on to do more complicated testing.
+.PP
+For such purposes we have \f(CW\*(C`use_ok\*(C'\fR and \f(CW\*(C`require_ok\*(C'\fR.
+.IP \fBrequire_ok\fR 4
+.IX Item "require_ok"
+.Vb 2
+\& require_ok($module);
+\& require_ok($file);
+.Ve
+.Sp
+Tries to \f(CW\*(C`require\*(C'\fR the given \f(CW$module\fR or \f(CW$file\fR. If it loads
+successfully, the test will pass. Otherwise it fails and displays the
+load error.
+.Sp
+\&\f(CW\*(C`require_ok\*(C'\fR will guess whether the input is a module name or a
+filename.
+.Sp
+No exception will be thrown if the load fails.
+.Sp
+.Vb 2
+\& # require Some::Module
+\& require_ok "Some::Module";
+\&
+\& # require "Some/File.pl";
+\& require_ok "Some/File.pl";
+\&
+\& # stop testing if any of your modules will not load
+\& for my $module (@module) {
+\& require_ok $module or BAIL_OUT "Can\*(Aqt load $module";
+\& }
+.Ve
+.IP \fBuse_ok\fR 4
+.IX Item "use_ok"
+.Vb 2
+\& BEGIN { use_ok($module); }
+\& BEGIN { use_ok($module, @imports); }
+.Ve
+.Sp
+Like \f(CW\*(C`require_ok\*(C'\fR, but it will \f(CW\*(C`use\*(C'\fR the \f(CW$module\fR in question and
+only loads modules, not files.
+.Sp
+If you just want to test a module can be loaded, use \f(CW\*(C`require_ok\*(C'\fR.
+.Sp
+If you just want to load a module in a test, we recommend simply using
+\&\f(CW\*(C`use\*(C'\fR directly. It will cause the test to stop.
+.Sp
+It's recommended that you run \f(CWuse_ok()\fR inside a BEGIN block so its
+functions are exported at compile-time and prototypes are properly
+honored.
+.Sp
+If \f(CW@imports\fR are given, they are passed through to the use. So this:
+.Sp
+.Vb 1
+\& BEGIN { use_ok(\*(AqSome::Module\*(Aq, qw(foo bar)) }
+.Ve
+.Sp
+is like doing this:
+.Sp
+.Vb 1
+\& use Some::Module qw(foo bar);
+.Ve
+.Sp
+Version numbers can be checked like so:
+.Sp
+.Vb 2
+\& # Just like "use Some::Module 1.02"
+\& BEGIN { use_ok(\*(AqSome::Module\*(Aq, 1.02) }
+.Ve
+.Sp
+Don't try to do this:
+.Sp
+.Vb 2
+\& BEGIN {
+\& use_ok(\*(AqSome::Module\*(Aq);
+\&
+\& ...some code that depends on the use...
+\& ...happening at compile time...
+\& }
+.Ve
+.Sp
+because the notion of "compile-time" is relative. Instead, you want:
+.Sp
+.Vb 2
+\& BEGIN { use_ok(\*(AqSome::Module\*(Aq) }
+\& BEGIN { ...some code that depends on the use... }
+.Ve
+.Sp
+If you want the equivalent of \f(CW\*(C`use Foo ()\*(C'\fR, use a module but not
+import anything, use \f(CW\*(C`require_ok\*(C'\fR.
+.Sp
+.Vb 1
+\& BEGIN { require_ok "Foo" }
+.Ve
+.SS "Complex data structures"
+.IX Subsection "Complex data structures"
+Not everything is a simple eq check or regex. There are times you
+need to see if two data structures are equivalent. For these
+instances Test::More provides a handful of useful functions.
+.PP
+\&\fBNOTE\fR I'm not quite sure what will happen with filehandles.
+.IP \fBis_deeply\fR 4
+.IX Item "is_deeply"
+.Vb 1
+\& is_deeply( $got, $expected, $test_name );
+.Ve
+.Sp
+Similar to \f(CWis()\fR, except that if \f(CW$got\fR and \f(CW$expected\fR are references, it
+does a deep comparison walking each data structure to see if they are
+equivalent. If the two structures are different, it will display the
+place where they start differing.
+.Sp
+\&\f(CWis_deeply()\fR compares the dereferenced values of references, the
+references themselves (except for their type) are ignored. This means
+aspects such as blessing and ties are not considered "different".
+.Sp
+\&\f(CWis_deeply()\fR currently has very limited handling of function reference
+and globs. It merely checks if they have the same referent. This may
+improve in the future.
+.Sp
+Test::Differences and Test::Deep provide more in-depth functionality
+along these lines.
+.Sp
+\&\fBNOTE\fR \fBis_deeply()\fR has limitations when it comes to comparing strings and
+refs:
+.Sp
+.Vb 4
+\& my $path = path(\*(Aq.\*(Aq);
+\& my $hash = {};
+\& is_deeply( $path, "$path" ); # ok
+\& is_deeply( $hash, "$hash" ); # fail
+.Ve
+.Sp
+This happens because is_deeply will unoverload all arguments unconditionally.
+It is probably best not to use is_deeply with overloading. For legacy reasons
+this is not likely to ever be fixed. If you would like a much better tool for
+this you should see Test2::Suite Specifically Test2::Tools::Compare has
+an \f(CWis()\fR function that works like \f(CW\*(C`is_deeply\*(C'\fR with many improvements.
+.SS Diagnostics
+.IX Subsection "Diagnostics"
+If you pick the right test function, you'll usually get a good idea of
+what went wrong when it failed. But sometimes it doesn't work out
+that way. So here we have ways for you to write your own diagnostic
+messages which are safer than just \f(CW\*(C`print STDERR\*(C'\fR.
+.IP \fBdiag\fR 4
+.IX Item "diag"
+.Vb 1
+\& diag(@diagnostic_message);
+.Ve
+.Sp
+Prints a diagnostic message which is guaranteed not to interfere with
+test output. Like \f(CW\*(C`print\*(C'\fR \f(CW@diagnostic_message\fR is simply concatenated
+together.
+.Sp
+Returns false, so as to preserve failure.
+.Sp
+Handy for this sort of thing:
+.Sp
+.Vb 2
+\& ok( grep(/foo/, @users), "There\*(Aqs a foo user" ) or
+\& diag("Since there\*(Aqs no foo, check that /etc/bar is set up right");
+.Ve
+.Sp
+which would produce:
+.Sp
+.Vb 4
+\& not ok 42 \- There\*(Aqs a foo user
+\& # Failed test \*(AqThere\*(Aqs a foo user\*(Aq
+\& # in foo.t at line 52.
+\& # Since there\*(Aqs no foo, check that /etc/bar is set up right.
+.Ve
+.Sp
+You might remember \f(CW\*(C`ok() or diag()\*(C'\fR with the mnemonic \f(CWopen() or
+die()\fR.
+.Sp
+\&\fBNOTE\fR The exact formatting of the diagnostic output is still
+changing, but it is guaranteed that whatever you throw at it won't
+interfere with the test.
+.IP \fBnote\fR 4
+.IX Item "note"
+.Vb 1
+\& note(@diagnostic_message);
+.Ve
+.Sp
+Like \f(CWdiag()\fR, except the message will not be seen when the test is run
+in a harness. It will only be visible in the verbose TAP stream.
+.Sp
+Handy for putting in notes which might be useful for debugging, but
+don't indicate a problem.
+.Sp
+.Vb 1
+\& note("Tempfile is $tempfile");
+.Ve
+.IP \fBexplain\fR 4
+.IX Item "explain"
+.Vb 1
+\& my @dump = explain @diagnostic_message;
+.Ve
+.Sp
+Will dump the contents of any references in a human readable format.
+Usually you want to pass this into \f(CW\*(C`note\*(C'\fR or \f(CW\*(C`diag\*(C'\fR.
+.Sp
+Handy for things like...
+.Sp
+.Vb 1
+\& is_deeply($have, $want) || diag explain $have;
+.Ve
+.Sp
+or
+.Sp
+.Vb 2
+\& note explain \e%args;
+\& Some::Class\->method(%args);
+.Ve
+.SS "Conditional tests"
+.IX Subsection "Conditional tests"
+Sometimes running a test under certain conditions will cause the
+test script to die. A certain function or method isn't implemented
+(such as \f(CWfork()\fR on MacOS), some resource isn't available (like a
+net connection) or a module isn't available. In these cases it's
+necessary to skip tests, or declare that they are supposed to fail
+but will work in the future (a todo test).
+.PP
+For more details on the mechanics of skip and todo tests see
+Test::Harness.
+.PP
+The way Test::More handles this is with a named block. Basically, a
+block of tests which can be skipped over or made todo. It's best if I
+just show you...
+.IP "\fBSKIP: BLOCK\fR" 4
+.IX Item "SKIP: BLOCK"
+.Vb 2
+\& SKIP: {
+\& skip $why, $how_many if $condition;
+\&
+\& ...normal testing code goes here...
+\& }
+.Ve
+.Sp
+This declares a block of tests that might be skipped, \f(CW$how_many\fR tests
+there are, \f(CW$why\fR and under what \f(CW$condition\fR to skip them. An example is
+the easiest way to illustrate:
+.Sp
+.Vb 2
+\& SKIP: {
+\& eval { require HTML::Lint };
+\&
+\& skip "HTML::Lint not installed", 2 if $@;
+\&
+\& my $lint = new HTML::Lint;
+\& isa_ok( $lint, "HTML::Lint" );
+\&
+\& $lint\->parse( $html );
+\& is( $lint\->errors, 0, "No errors found in HTML" );
+\& }
+.Ve
+.Sp
+If the user does not have HTML::Lint installed, the whole block of
+code \fIwon't be run at all\fR. Test::More will output special ok's
+which Test::Harness interprets as skipped, but passing, tests.
+.Sp
+It's important that \f(CW$how_many\fR accurately reflects the number of tests
+in the SKIP block so the # of tests run will match up with your plan.
+If your plan is \f(CW\*(C`no_plan\*(C'\fR \f(CW$how_many\fR is optional and will default to 1.
+.Sp
+It's perfectly safe to nest SKIP blocks. Each SKIP block must have
+the label \f(CW\*(C`SKIP\*(C'\fR, or Test::More can't work its magic.
+.Sp
+You don't skip tests which are failing because there's a bug in your
+program, or for which you don't yet have code written. For that you
+use TODO. Read on.
+.IP "\fBTODO: BLOCK\fR" 4
+.IX Item "TODO: BLOCK"
+.Vb 2
+\& TODO: {
+\& local $TODO = $why if $condition;
+\&
+\& ...normal testing code goes here...
+\& }
+.Ve
+.Sp
+Declares a block of tests you expect to fail and \f(CW$why\fR. Perhaps it's
+because you haven't fixed a bug or haven't finished a new feature:
+.Sp
+.Vb 2
+\& TODO: {
+\& local $TODO = "URI::Geller not finished";
+\&
+\& my $card = "Eight of clubs";
+\& is( URI::Geller\->your_card, $card, \*(AqIs THIS your card?\*(Aq );
+\&
+\& my $spoon;
+\& URI::Geller\->bend_spoon;
+\& is( $spoon, \*(Aqbent\*(Aq, "Spoon bending, that\*(Aqs original" );
+\& }
+.Ve
+.Sp
+With a todo block, the tests inside are expected to fail. Test::More
+will run the tests normally, but print out special flags indicating
+they are "todo". Test::Harness will interpret failures as being ok.
+Should anything succeed, it will report it as an unexpected success.
+You then know the thing you had todo is done and can remove the
+TODO flag.
+.Sp
+The nice part about todo tests, as opposed to simply commenting out a
+block of tests, is that it is like having a programmatic todo list. You know
+how much work is left to be done, you're aware of what bugs there are,
+and you'll know immediately when they're fixed.
+.Sp
+Once a todo test starts succeeding, simply move it outside the block.
+When the block is empty, delete it.
+.Sp
+Note that, if you leave \f(CW$TODO\fR unset or undef, Test::More reports failures
+as normal. This can be useful to mark the tests as expected to fail only
+in certain conditions, e.g.:
+.Sp
+.Vb 2
+\& TODO: {
+\& local $TODO = "$^O doesn\*(Aqt work yet. :(" if !_os_is_supported($^O);
+\&
+\& ...
+\& }
+.Ve
+.IP \fBtodo_skip\fR 4
+.IX Item "todo_skip"
+.Vb 2
+\& TODO: {
+\& todo_skip $why, $how_many if $condition;
+\&
+\& ...normal testing code...
+\& }
+.Ve
+.Sp
+With todo tests, it's best to have the tests actually run. That way
+you'll know when they start passing. Sometimes this isn't possible.
+Often a failing test will cause the whole program to die or hang, even
+inside an \f(CW\*(C`eval BLOCK\*(C'\fR with and using \f(CW\*(C`alarm\*(C'\fR. In these extreme
+cases you have no choice but to skip over the broken tests entirely.
+.Sp
+The syntax and behavior is similar to a \f(CW\*(C`SKIP: BLOCK\*(C'\fR except the
+tests will be marked as failing but todo. Test::Harness will
+interpret them as passing.
+.IP "When do I use SKIP vs. TODO?" 4
+.IX Item "When do I use SKIP vs. TODO?"
+\&\fBIf it's something the user might not be able to do\fR, use SKIP.
+This includes optional modules that aren't installed, running under
+an OS that doesn't have some feature (like \f(CWfork()\fR or symlinks), or maybe
+you need an Internet connection and one isn't available.
+.Sp
+\&\fBIf it's something the programmer hasn't done yet\fR, use TODO. This
+is for any code you haven't written yet, or bugs you have yet to fix,
+but want to put tests in your testing script (always a good idea).
+.SS "Test control"
+.IX Subsection "Test control"
+.IP \fBBAIL_OUT\fR 4
+.IX Item "BAIL_OUT"
+.Vb 1
+\& BAIL_OUT($reason);
+.Ve
+.Sp
+Indicates to the harness that things are going so badly all testing
+should terminate. This includes the running of any additional test scripts.
+.Sp
+This is typically used when testing cannot continue such as a critical
+module failing to compile or a necessary external utility not being
+available such as a database connection failing.
+.Sp
+The test will exit with 255.
+.Sp
+For even better control look at Test::Most.
+.SS "Discouraged comparison functions"
+.IX Subsection "Discouraged comparison functions"
+The use of the following functions is discouraged as they are not
+actually testing functions and produce no diagnostics to help figure
+out what went wrong. They were written before \f(CWis_deeply()\fR existed
+because I couldn't figure out how to display a useful diff of two
+arbitrary data structures.
+.PP
+These functions are usually used inside an \f(CWok()\fR.
+.PP
+.Vb 1
+\& ok( eq_array(\e@got, \e@expected) );
+.Ve
+.PP
+\&\f(CWis_deeply()\fR can do that better and with diagnostics.
+.PP
+.Vb 1
+\& is_deeply( \e@got, \e@expected );
+.Ve
+.PP
+They may be deprecated in future versions.
+.IP \fBeq_array\fR 4
+.IX Item "eq_array"
+.Vb 1
+\& my $is_eq = eq_array(\e@got, \e@expected);
+.Ve
+.Sp
+Checks if two arrays are equivalent. This is a deep check, so
+multi-level structures are handled correctly.
+.IP \fBeq_hash\fR 4
+.IX Item "eq_hash"
+.Vb 1
+\& my $is_eq = eq_hash(\e%got, \e%expected);
+.Ve
+.Sp
+Determines if the two hashes contain the same keys and values. This
+is a deep check.
+.IP \fBeq_set\fR 4
+.IX Item "eq_set"
+.Vb 1
+\& my $is_eq = eq_set(\e@got, \e@expected);
+.Ve
+.Sp
+Similar to \f(CWeq_array()\fR, except the order of the elements is \fBnot\fR
+important. This is a deep check, but the irrelevancy of order only
+applies to the top level.
+.Sp
+.Vb 1
+\& ok( eq_set(\e@got, \e@expected) );
+.Ve
+.Sp
+Is better written:
+.Sp
+.Vb 1
+\& is_deeply( [sort @got], [sort @expected] );
+.Ve
+.Sp
+\&\fBNOTE\fR By historical accident, this is not a true set comparison.
+While the order of elements does not matter, duplicate elements do.
+.Sp
+\&\fBNOTE\fR \f(CWeq_set()\fR does not know how to deal with references at the top
+level. The following is an example of a comparison which might not work:
+.Sp
+.Vb 1
+\& eq_set([\e1, \e2], [\e2, \e1]);
+.Ve
+.Sp
+Test::Deep contains much better set comparison functions.
+.SS "Extending and Embedding Test::More"
+.IX Subsection "Extending and Embedding Test::More"
+Sometimes the Test::More interface isn't quite enough. Fortunately,
+Test::More is built on top of Test::Builder which provides a single,
+unified backend for any test library to use. This means two test
+libraries which both use Test::Builder \fBcan\fR be used together in the
+same program.
+.PP
+If you simply want to do a little tweaking of how the tests behave,
+you can access the underlying Test::Builder object like so:
+.IP \fBbuilder\fR 4
+.IX Item "builder"
+.Vb 1
+\& my $test_builder = Test::More\->builder;
+.Ve
+.Sp
+Returns the Test::Builder object underlying Test::More for you to play
+with.
+.SH "EXIT CODES"
+.IX Header "EXIT CODES"
+If all your tests passed, Test::Builder will exit with zero (which is
+normal). If anything failed it will exit with how many failed. If
+you run less (or more) tests than you planned, the missing (or extras)
+will be considered failures. If no tests were ever run Test::Builder
+will throw a warning and exit with 255. If the test died, even after
+having successfully completed all its tests, it will still be
+considered a failure and will exit with 255.
+.PP
+So the exit codes are...
+.PP
+.Vb 3
+\& 0 all tests successful
+\& 255 test died or all passed but wrong # of tests run
+\& any other number how many failed (including missing or extras)
+.Ve
+.PP
+If you fail more than 254 tests, it will be reported as 254.
+.PP
+\&\fBNOTE\fR This behavior may go away in future versions.
+.SH COMPATIBILITY
+.IX Header "COMPATIBILITY"
+Test::More works with Perls as old as 5.8.1.
+.PP
+Thread support is not very reliable before 5.10.1, but that's
+because threads are not very reliable before 5.10.1.
+.PP
+Although Test::More has been a core module in versions of Perl since 5.6.2, Test::More has evolved since then, and not all of the features you're used to will be present in the shipped version of Test::More. If you are writing a module, don't forget to indicate in your package metadata the minimum version of Test::More that you require. For instance, if you want to use \f(CWdone_testing()\fR but want your test script to run on Perl 5.10.0, you will need to explicitly require Test::More > 0.88.
+.PP
+Key feature milestones include:
+.IP subtests 4
+.IX Item "subtests"
+Subtests were released in Test::More 0.94, which came with Perl 5.12.0. Subtests did not implicitly call \f(CWdone_testing()\fR until 0.96; the first Perl with that fix was Perl 5.14.0 with 0.98.
+.ie n .IP done_testing() 4
+.el .IP \f(CWdone_testing()\fR 4
+.IX Item "done_testing()"
+This was released in Test::More 0.88 and first shipped with Perl in 5.10.1 as part of Test::More 0.92.
+.ie n .IP cmp_ok() 4
+.el .IP \f(CWcmp_ok()\fR 4
+.IX Item "cmp_ok()"
+Although \f(CWcmp_ok()\fR was introduced in 0.40, 0.86 fixed an important bug to make it safe for overloaded objects; the fixed first shipped with Perl in 5.10.1 as part of Test::More 0.92.
+.ie n .IP "new_ok() note() and explain()" 4
+.el .IP "\f(CWnew_ok()\fR \f(CWnote()\fR and \f(CWexplain()\fR" 4
+.IX Item "new_ok() note() and explain()"
+These were was released in Test::More 0.82, and first shipped with Perl in 5.10.1 as part of Test::More 0.92.
+.PP
+There is a full version history in the Changes file, and the Test::More versions included as core can be found using Module::CoreList:
+.PP
+.Vb 1
+\& $ corelist \-a Test::More
+.Ve
+.SH "CAVEATS and NOTES"
+.IX Header "CAVEATS and NOTES"
+.IP "utf8 / ""Wide character in print""" 4
+.IX Item "utf8 / ""Wide character in print"""
+If you use utf8 or other non-ASCII characters with Test::More you
+might get a "Wide character in print" warning. Using
+\&\f(CW\*(C`binmode STDOUT, ":utf8"\*(C'\fR will not fix it.
+Test::Builder (which powers
+Test::More) duplicates STDOUT and STDERR. So any changes to them,
+including changing their output disciplines, will not be seen by
+Test::More.
+.Sp
+One work around is to apply encodings to STDOUT and STDERR as early
+as possible and before Test::More (or any other Test module) loads.
+.Sp
+.Vb 2
+\& use open \*(Aq:std\*(Aq, \*(Aq:encoding(utf8)\*(Aq;
+\& use Test::More;
+.Ve
+.Sp
+A more direct work around is to change the filehandles used by
+Test::Builder.
+.Sp
+.Vb 4
+\& my $builder = Test::More\->builder;
+\& binmode $builder\->output, ":encoding(utf8)";
+\& binmode $builder\->failure_output, ":encoding(utf8)";
+\& binmode $builder\->todo_output, ":encoding(utf8)";
+.Ve
+.IP "Overloaded objects" 4
+.IX Item "Overloaded objects"
+String overloaded objects are compared \fBas strings\fR (or in \f(CWcmp_ok()\fR's
+case, strings or numbers as appropriate to the comparison op). This
+prevents Test::More from piercing an object's interface allowing
+better blackbox testing. So if a function starts returning overloaded
+objects instead of bare strings your tests won't notice the
+difference. This is good.
+.Sp
+However, it does mean that functions like \f(CWis_deeply()\fR cannot be used to
+test the internals of string overloaded objects. In this case I would
+suggest Test::Deep which contains more flexible testing functions for
+complex data structures.
+.IP Threads 4
+.IX Item "Threads"
+Test::More will only be aware of threads if \f(CW\*(C`use threads\*(C'\fR has been done
+\&\fIbefore\fR Test::More is loaded. This is ok:
+.Sp
+.Vb 2
+\& use threads;
+\& use Test::More;
+.Ve
+.Sp
+This may cause problems:
+.Sp
+.Vb 2
+\& use Test::More
+\& use threads;
+.Ve
+.Sp
+5.8.1 and above are supported. Anything below that has too many bugs.
+.SH HISTORY
+.IX Header "HISTORY"
+This is a case of convergent evolution with Joshua Pritikin's Test
+module. I was largely unaware of its existence when I'd first
+written my own \f(CWok()\fR routines. This module exists because I can't
+figure out how to easily wedge test names into Test's interface (along
+with a few other problems).
+.PP
+The goal here is to have a testing utility that's simple to learn,
+quick to use and difficult to trip yourself up with while still
+providing more flexibility than the existing Test.pm. As such, the
+names of the most common routines are kept tiny, special cases and
+magic side-effects are kept to a minimum. WYSIWYG.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+.SS ""
+.IX Subsection ""
+.SS ALTERNATIVES
+.IX Subsection "ALTERNATIVES"
+Test2::Suite is the most recent and modern set of tools for testing.
+.PP
+Test::Simple if all this confuses you and you just want to write
+some tests. You can upgrade to Test::More later (it's forward
+compatible).
+.PP
+Test::Legacy tests written with Test.pm, the original testing
+module, do not play well with other testing libraries. Test::Legacy
+emulates the Test.pm interface and does play well with others.
+.SS "ADDITIONAL LIBRARIES"
+.IX Subsection "ADDITIONAL LIBRARIES"
+Test::Differences for more ways to test complex data structures.
+And it plays well with Test::More.
+.PP
+Test::Class is like xUnit but more perlish.
+.PP
+Test::Deep gives you more powerful complex data structure testing.
+.PP
+Test::Inline shows the idea of embedded testing.
+.PP
+Mock::Quick The ultimate mocking library. Easily spawn objects defined on
+the fly. Can also override, block, or reimplement packages as needed.
+.PP
+Test::FixtureBuilder Quickly define fixture data for unit tests.
+.SS "OTHER COMPONENTS"
+.IX Subsection "OTHER COMPONENTS"
+Test::Harness is the test runner and output interpreter for Perl.
+It's the thing that powers \f(CW\*(C`make test\*(C'\fR and where the \f(CW\*(C`prove\*(C'\fR utility
+comes from.
+.SS BUNDLES
+.IX Subsection "BUNDLES"
+Test::Most Most commonly needed test functions and features.
+.SH AUTHORS
+.IX Header "AUTHORS"
+Michael G Schwern <schwern@pobox.com> with much inspiration
+from Joshua Pritikin's Test module and lots of help from Barrie
+Slaymaker, Tony Bowden, blackstar.co.uk, chromatic, Fergal Daly and
+the perl-qa gang.
+.SH MAINTAINERS
+.IX Header "MAINTAINERS"
+.IP "Chad Granum <exodist@cpan.org>" 4
+.IX Item "Chad Granum <exodist@cpan.org>"
+.SH BUGS
+.IX Header "BUGS"
+See \fIhttps://github.com/Test\-More/test\-more/issues\fR to report and view bugs.
+.SH SOURCE
+.IX Header "SOURCE"
+The source code repository for Test::More can be found at
+\&\fIhttp://github.com/Test\-More/test\-more/\fR.
+.SH COPYRIGHT
+.IX Header "COPYRIGHT"
+Copyright 2001\-2008 by Michael G Schwern <schwern@pobox.com>.
+.PP
+This program is free software; you can redistribute it and/or
+modify it under the same terms as Perl itself.
+.PP
+See \fIhttp://www.perl.com/perl/misc/Artistic.html\fR