diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-15 19:43:11 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-15 19:43:11 +0000 |
commit | fc22b3d6507c6745911b9dfcc68f1e665ae13dbc (patch) | |
tree | ce1e3bce06471410239a6f41282e328770aa404a /upstream/mageia-cauldron/man3pm/Test::More.3pm | |
parent | Initial commit. (diff) | |
download | manpages-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.3pm | 1319 |
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 |