This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
Update Test-Simple to CPAN version 1.001006
authorChris 'BinGOs' Williams <chris@bingosnet.co.uk>
Wed, 3 Sep 2014 13:10:20 +0000 (14:10 +0100)
committerChris 'BinGOs' Williams <chris@bingosnet.co.uk>
Wed, 3 Sep 2014 13:57:33 +0000 (14:57 +0100)
  [DELTA]

1.001005     Tue Sep  2 19:47:19:00 JST 2014
    * Changed install path for perl 5.12 or higher.

1.001004_003 Sat May  17 13:43:00 PST 2014
    * Another Minor doc fix to solve test bug
    * Fix #399, conflict with strawberry-portable

1.001004_002 Sat May  17 13:43:00 PST 2014
    * Minor doc fix to solve test bug

1.001004_001 Sat May  10 08:39:00 PST 2014
    * Doc updates
    * Subtests accept args
    * Outdent subtest diag

Porting/Maintainers.pl
cpan/Test-Simple/lib/Test/Builder.pm
cpan/Test-Simple/lib/Test/Builder/Module.pm
cpan/Test-Simple/lib/Test/Builder/Tester.pm
cpan/Test-Simple/lib/Test/Builder/Tester/Color.pm
cpan/Test-Simple/lib/Test/More.pm
cpan/Test-Simple/lib/Test/Simple.pm
cpan/Test-Simple/lib/Test/Tutorial.pod
cpan/Test-Simple/t/dont_overwrite_die_handler.t
cpan/Test-Simple/t/subtest/args.t

index 8a0b61c..10b2a5d 100755 (executable)
@@ -1050,7 +1050,7 @@ use File::Glob qw(:case);
     },
 
     'Test::Simple' => {
-        'DISTRIBUTION' => 'EXODIST/Test-Simple-1.001003.tar.gz',
+        'DISTRIBUTION' => 'EXODIST/Test-Simple-1.001006.tar.gz',
         'FILES'        => q[cpan/Test-Simple],
         'EXCLUDED'     => [
             qr{^t/xt},
index 00a3ec5..31933b3 100644 (file)
@@ -4,7 +4,7 @@ use 5.006;
 use strict;
 use warnings;
 
-our $VERSION = '1.001003';
+our $VERSION = '1.001006';
 $VERSION = eval $VERSION;    ## no critic (BuiltinFunctions::ProhibitStringyEval)
 
 BEGIN {
@@ -89,7 +89,7 @@ Test::Builder - Backend for building test libraries
 
 =head1 DESCRIPTION
 
-Test::Simple and Test::More have proven to be popular testing modules,
+L<Test::Simple> and L<Test::More> have proven to be popular testing modules,
 but they're not always flexible enough.  Test::Builder provides a
 building block upon which to write your own test libraries I<which can
 work together>.
@@ -223,15 +223,18 @@ sub child {
 
 =item B<subtest>
 
-    $builder->subtest($name, \&subtests);
+    $builder->subtest($name, \&subtests, @args);
 
-See documentation of C<subtest> in Test::More.
+See documentation of C<subtest> in Test::More.  
+
+C<subtest> also, and optionally, accepts arguments which will be passed to the
+subtests reference.
 
 =cut
 
 sub subtest {
     my $self = shift;
-    my($name, $subtests) = @_;
+    my($name, $subtests, @args) = @_;
 
     if ('CODE' ne ref $subtests) {
         $self->croak("subtest()'s second argument must be a code ref");
@@ -255,7 +258,7 @@ sub subtest {
         my $run_the_subtests = sub {
             # Add subtest name for clarification of starting point
             $self->note("Subtest: $name");
-            $subtests->();
+            $subtests->(@args);
             $self->done_testing unless $self->_plan_handled;
             1;
         };
@@ -321,7 +324,7 @@ sub _plan_handled {
 When your child is done running tests, you must call C<finalize> to clean up
 and tell the parent your pass/fail status.
 
-Calling finalize on a child with open children will C<croak>.
+Calling C<finalize> on a child with open children will C<croak>.
 
 If the child falls out of scope before C<finalize> is called, a failure
 diagnostic will be issued and the child is considered to have failed.
@@ -1062,14 +1065,14 @@ DIAGNOSTIC
 
   $Test->isnt_eq($got, $dont_expect, $name);
 
-Like Test::More's C<isnt()>.  Checks if C<$got ne $dont_expect>.  This is
+Like L<Test::More>'s C<isnt()>.  Checks if C<$got ne $dont_expect>.  This is
 the string version.
 
 =item B<isnt_num>
 
   $Test->isnt_num($got, $dont_expect, $name);
 
-Like Test::More's C<isnt()>.  Checks if C<$got ne $dont_expect>.  This is
+Like L<Test::More>'s C<isnt()>.  Checks if C<$got ne $dont_expect>.  This is
 the numeric version.
 
 =cut
@@ -1111,14 +1114,14 @@ sub isnt_num {
   $Test->like($thing, qr/$regex/, $name);
   $Test->like($thing, '/$regex/', $name);
 
-Like Test::More's C<like()>.  Checks if $thing matches the given C<$regex>.
+Like L<Test::More>'s C<like()>.  Checks if $thing matches the given C<$regex>.
 
 =item B<unlike>
 
   $Test->unlike($thing, qr/$regex/, $name);
   $Test->unlike($thing, '/$regex/', $name);
 
-Like Test::More's C<unlike()>.  Checks if $thing B<does not match> the
+Like L<Test::More>'s C<unlike()>.  Checks if $thing B<does not match> the
 given C<$regex>.
 
 =cut
@@ -1141,7 +1144,7 @@ sub unlike {
 
   $Test->cmp_ok($thing, $type, $that, $name);
 
-Works just like Test::More's C<cmp_ok()>.
+Works just like L<Test::More>'s C<cmp_ok()>.
 
     $Test->cmp_ok($big_num, '!=', $other_big_num);
 
@@ -1246,7 +1249,7 @@ These are methods which are used in the course of writing a test but are not the
 
     $Test->BAIL_OUT($reason);
 
-Indicates to the Test::Harness that things are going so badly all
+Indicates to the L<Test::Harness> that things are going so badly all
 testing should terminate.  This includes running any additional test
 scripts.
 
@@ -2201,7 +2204,7 @@ pretty good at guessing the right package to look at.  It first looks for
 the caller based on C<$Level + 1>, since C<todo()> is usually called inside
 a test function.  As a last resort it will use C<exported_to()>.
 
-Sometimes there is some confusion about where todo() should be looking
+Sometimes there is some confusion about where C<todo()> should be looking
 for the C<$TODO> variable.  If you want to be sure, tell it explicitly
 what $pack to use.
 
@@ -2616,7 +2619,7 @@ Test::Builder.
 
 =head1 MEMORY
 
-An informative hash, accessible via C<<details()>>, is stored for each
+An informative hash, accessible via C<details()>, is stored for each
 test you perform.  So memory usage will scale linearly with each test
 run. Although this is not a problem for most test suites, it can
 become an issue if you do large (hundred thousands to million)
@@ -2624,19 +2627,19 @@ combinatorics tests in the same run.
 
 In such cases, you are advised to either split the test file into smaller
 ones, or use a reverse approach, doing "normal" (code) compares and
-triggering fail() should anything go unexpected.
+triggering C<fail()> should anything go unexpected.
 
 Future versions of Test::Builder will have a way to turn history off.
 
 
 =head1 EXAMPLES
 
-CPAN can provide the best examples.  Test::Simple, Test::More,
-Test::Exception and Test::Differences all use Test::Builder.
+CPAN can provide the best examples.  L<Test::Simple>, L<Test::More>,
+L<Test::Exception> and L<Test::Differences> all use Test::Builder.
 
 =head1 SEE ALSO
 
-Test::Simple, Test::More, Test::Harness
+L<Test::Simple>, L<Test::More>, L<Test::Harness>
 
 =head1 AUTHORS
 
index a11033e..50c2957 100644 (file)
@@ -7,7 +7,7 @@ use Test::Builder 0.99;
 require Exporter;
 our @ISA = qw(Exporter);
 
-our $VERSION = '1.001003';
+our $VERSION = '1.001006';
 $VERSION = eval $VERSION;      ## no critic (BuiltinFunctions::ProhibitStringyEval)
 
 
@@ -35,41 +35,41 @@ Test::Builder::Module - Base class for test modules
 
 =head1 DESCRIPTION
 
-This is a superclass for Test::Builder-based modules.  It provides a
+This is a superclass for L<Test::Builder>-based modules.  It provides a
 handful of common functionality and a method of getting at the underlying
-Test::Builder object.
+L<Test::Builder> object.
 
 
 =head2 Importing
 
-Test::Builder::Module is a subclass of Exporter which means your
+Test::Builder::Module is a subclass of L<Exporter> which means your
 module is also a subclass of Exporter.  @EXPORT, @EXPORT_OK, etc...
 all act normally.
 
-A few methods are provided to do the C<use Your::Module tests => 23> part
+A few methods are provided to do the C<< use Your::Module tests => 23 >> part
 for you.
 
 =head3 import
 
-Test::Builder::Module provides an import() method which acts in the
-same basic way as Test::More's, setting the plan and controlling
+Test::Builder::Module provides an C<import()> method which acts in the
+same basic way as L<Test::More>'s, setting the plan and controlling
 exporting of functions and variables.  This allows your module to set
-the plan independent of Test::More.
+the plan independent of L<Test::More>.
 
-All arguments passed to import() are passed onto 
+All arguments passed to C<import()> are passed onto 
 C<< Your::Module->builder->plan() >> with the exception of 
 C<< import =>[qw(things to import)] >>.
 
     use Your::Module import => [qw(this that)], tests => 23;
 
-says to import the functions this() and that() as well as set the plan
+says to import the functions C<this()> and C<that()> as well as set the plan
 to be 23 tests.
 
-import() also sets the exported_to() attribute of your builder to be
-the caller of the import() function.
+C<import()> also sets the C<exported_to()> attribute of your builder to be
+the caller of the C<import()> function.
 
-Additional behaviors can be added to your import() method by overriding
-import_extra().
+Additional behaviors can be added to your C<import()> method by overriding
+C<import_extra()>.
 
 =cut
 
@@ -123,13 +123,13 @@ sub _strip_imports {
 
     Your::Module->import_extra(\@import_args);
 
-import_extra() is called by import().  It provides an opportunity for you
+C<import_extra()> is called by C<import()>.  It provides an opportunity for you
 to add behaviors to your module based on its import list.
 
-Any extra arguments which shouldn't be passed on to plan() should be 
+Any extra arguments which shouldn't be passed on to C<plan()> should be
 stripped off by this method.
 
-See Test::More for an example of its use.
+See L<Test::More> for an example of its use.
 
 B<NOTE> This mechanism is I<VERY ALPHA AND LIKELY TO CHANGE> as it
 feels like a bit of an ugly hack in its current form.
@@ -147,15 +147,15 @@ Test::Builder object.
 
   my $builder = Your::Class->builder;
 
-This method returns the Test::Builder object associated with Your::Class.
+This method returns the L<Test::Builder> object associated with Your::Class.
 It is not a constructor so you can call it as often as you like.
 
-This is the preferred way to get the Test::Builder object.  You should
+This is the preferred way to get the L<Test::Builder> object.  You should
 I<not> get it via C<< Test::Builder->new >> as was previously
 recommended.
 
-The object returned by builder() may change at runtime so you should
-call builder() inside each function rather than store it in a global.
+The object returned by C<builder()> may change at runtime so you should
+call C<builder()> inside each function rather than store it in a global.
 
   sub ok {
       my $builder = Your::Class->builder;
index 5128be9..5dd8436 100644 (file)
@@ -1,7 +1,7 @@
 package Test::Builder::Tester;
 
 use strict;
-our $VERSION = "1.23_003";
+our $VERSION = "1.24";
 
 use Test::Builder 0.98;
 use Symbol;
@@ -25,20 +25,20 @@ Test::Builder
 =head1 DESCRIPTION
 
 A module that helps you test testing modules that are built with
-B<Test::Builder>.
+L<Test::Builder>.
 
 The testing system is designed to be used by performing a three step
 process for each test you wish to test.  This process starts with using
 C<test_out> and C<test_err> in advance to declare what the testsuite you
-are testing will output with B<Test::Builder> to stdout and stderr.
+are testing will output with L<Test::Builder> to stdout and stderr.
 
 You then can run the test(s) from your test suite that call
-B<Test::Builder>.  At this point the output of B<Test::Builder> is
-safely captured by B<Test::Builder::Tester> rather than being
+L<Test::Builder>.  At this point the output of L<Test::Builder> is
+safely captured by L<Test::Builder::Tester> rather than being
 interpreted as real test output.
 
 The final stage is to call C<test_test> that will simply compare what you
-predeclared to what B<Test::Builder> actually outputted, and report the
+predeclared to what L<Test::Builder> actually outputted, and report the
 results back with a "ok" or "not ok" (with debugging) to the normal
 output.
 
@@ -165,8 +165,8 @@ which is even the same as
    test_out("ok 2");
 
 Once C<test_out> or C<test_err> (or C<test_fail> or C<test_diag>) have
-been called, all further output from B<Test::Builder> will be
-captured by B<Test::Builder::Tester>.  This means that you will not
+been called, all further output from L<Test::Builder> will be
+captured by L<Test::Builder::Tester>.  This means that you will not
 be able perform further tests to the normal output in the normal way
 until you call C<test_test> (well, unless you manually meddle with the
 output filehandles)
@@ -189,7 +189,7 @@ sub test_err {
 
 =item test_fail
 
-Because the standard failure message that B<Test::Builder> produces
+Because the standard failure message that L<Test::Builder> produces
 whenever a test fails will be a common occurrence in your test error
 output, and because it has changed between Test::Builder versions, rather
 than forcing you to call C<test_err> with the string all the time like
@@ -228,7 +228,7 @@ sub test_fail {
 =item test_diag
 
 As most of the remaining expected output to the error stream will be
-created by Test::Builder's C<diag> function, B<Test::Builder::Tester>
+created by L<Test::Builder>'s C<diag> function, L<Test::Builder::Tester>
 provides a convenience function C<test_diag> that you can use instead of
 C<test_err>.
 
@@ -242,7 +242,7 @@ you can write
 
    test_diag("Couldn't open file");
 
-Remember that B<Test::Builder>'s diag function will not add newlines to
+Remember that L<Test::Builder>'s diag function will not add newlines to
 the end of output and test_diag will. So to check
 
    Test::Builder->new->diag("foo\n","bar\n");
@@ -267,7 +267,7 @@ sub test_diag {
 =item test_test
 
 Actually performs the output check testing the tests, comparing the
-data (with C<eq>) that we have captured from B<Test::Builder> against
+data (with C<eq>) that we have captured from L<Test::Builder> against
 what was declared with C<test_out> and C<test_err>.
 
 This takes name/value pairs that effect how the test is run.
@@ -297,9 +297,9 @@ As a convenience, if only one argument is passed then this argument
 is assumed to be the name of the test (as in the above examples.)
 
 Once C<test_test> has been run test output will be redirected back to
-the original filehandles that B<Test::Builder> was connected to
+the original filehandles that L<Test::Builder> was connected to
 (probably STDOUT and STDERR,) meaning any further tests you run
-will function normally and cause success/errors for B<Test::Harness>.
+will function normally and cause success/errors for L<Test::Harness>.
 
 =cut
 
@@ -400,11 +400,11 @@ respectively, and the function called with no argument will return the
 current setting.
 
 To enable colouring from the command line, you can use the
-B<Text::Builder::Tester::Color> module like so:
+L<Text::Builder::Tester::Color> module like so:
 
    perl -Mlib=Text::Builder::Tester::Color test.t
 
-Or by including the B<Test::Builder::Tester::Color> module directly in
+Or by including the L<Test::Builder::Tester::Color> module directly in
 the PERL5LIB.
 
 =cut
@@ -420,12 +420,12 @@ sub color {
 
 =head1 BUGS
 
-Calls C<<Test::Builder->no_ending>> turning off the ending tests.
+Calls C<< Test::Builder->no_ending >> turning off the ending tests.
 This is needed as otherwise it will trip out because we've run more
 tests than we strictly should have and it'll register any failures we
 had that we were testing for as real failures.
 
-The color function doesn't work unless B<Term::ANSIColor> is
+The color function doesn't work unless L<Term::ANSIColor> is
 compatible with your terminal.
 
 Bugs (and requests for new features) can be reported to the author
@@ -436,7 +436,7 @@ L<http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Test-Builder-Tester>
 
 Copyright Mark Fowler E<lt>mark@twoshortplanks.comE<gt> 2002, 2004.
 
-Some code taken from B<Test::More> and B<Test::Catch>, written by
+Some code taken from L<Test::More> and L<Test::Catch>, written by
 Michael G Schwern E<lt>schwern@pobox.comE<gt>.  Hence, those parts
 Copyright Micheal G Schwern 2001.  Used and distributed with
 permission.
index b269a27..4cb3b15 100644 (file)
@@ -1,7 +1,7 @@
 package Test::Builder::Tester::Color;
 
 use strict;
-our $VERSION = "1.23_002";
+our $VERSION = "1.24";
 
 require Test::Builder::Tester;
 
index 217ad59..ca178bb 100644 (file)
@@ -9,7 +9,7 @@ use warnings;
 # We use a lot of subroutine prototypes
 ## no critic (Subroutines::ProhibitSubroutinePrototypes)
 
-# Can't use Carp because it might cause use_ok() to accidentally succeed
+# Can't use Carp because it might cause C<use_ok()> to accidentally succeed
 # even though the module being used forgot to use Carp.  Yes, this
 # actually happened.
 sub _carp {
@@ -17,7 +17,7 @@ sub _carp {
     return warn @_, " at $file line $line\n";
 }
 
-our $VERSION = '1.001003';
+our $VERSION = '1.001006';
 $VERSION = eval $VERSION;    ## no critic (BuiltinFunctions::ProhibitStringyEval)
 
 use Test::Builder::Module 0.99;
@@ -144,7 +144,7 @@ but 'fail', you'd do:
 
   use Test::More tests => 23, import => ['!fail'];
 
-Alternatively, you can use the plan() function.  Useful for when you
+Alternatively, you can use the C<plan()> function.  Useful for when you
 have to calculate the number of tests.
 
   use Test::More;
@@ -204,7 +204,7 @@ sub import_extra {
 If you don't know how many tests you're going to run, you can issue
 the plan when you're done running tests.
 
-$number_of_tests is the same as plan(), it's the number of tests you
+$number_of_tests is the same as C<plan()>, 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.
@@ -277,13 +277,13 @@ out.  It makes it very easy to find a test in your script when it fails
 and gives others an idea of your intentions.  $test_name is optional,
 but we B<very> strongly encourage its use.
 
-Should an ok() fail, it will produce some diagnostics:
+Should an C<ok()> fail, it will produce some diagnostics:
 
     not ok 18 - sufficient mucus
     #   Failed test 'sufficient mucus'
     #   in foo.t at line 42.
 
-This is the same as Test::Simple's ok() routine.
+This is the same as L<Test::Simple>'s C<ok()> routine.
 
 =cut
 
@@ -301,7 +301,7 @@ sub ok ($;$) {
   is  ( $got, $expected, $test_name );
   isnt( $got, $expected, $test_name );
 
-Similar to ok(), is() and isnt() compare their two arguments
+Similar to C<ok()>, C<is()> and C<isnt()> compare their two arguments
 with C<eq> and C<ne> respectively and use the result of that to
 determine if the test succeeded or failed.  So these:
 
@@ -323,9 +323,9 @@ against C<undef> like this:
 
 (Mnemonic:  "This is that."  "This isn't that.")
 
-So why use these?  They produce better diagnostics on failure.  ok()
-cannot know what you are testing for (beyond the name), but is() and
-isnt() know what the test was and why it failed.  For example this
+So why use these?  They produce better diagnostics on failure.  C<ok()>
+cannot know what you are testing for (beyond the name), but C<is()> and
+C<isnt()> know what the test was and why it failed.  For example this
 test:
 
     my $foo = 'waffle';  my $bar = 'yarblokos';
@@ -341,7 +341,7 @@ Will produce something like this:
 
 So you can figure out what went wrong without rerunning the test.
 
-You are encouraged to use is() and isnt() over ok() where possible,
+You are encouraged to use C<is()> and C<isnt()> over C<ok()> where possible,
 however do not be tempted to use them to find out if something is
 true or false!
 
@@ -350,11 +350,11 @@ true or false!
 
 This does not check if C<exists $brooklyn{tree}> is true, it checks if
 it returns 1.  Very different.  Similar caveats exist for false and 0.
-In these cases, use ok().
+In these cases, use C<ok()>.
 
   ok( exists $brooklyn{tree},    'A tree grows in Brooklyn' );
 
-A simple call to isnt() usually does not provide a strong test but there
+A simple call to C<isnt()> 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:
 
@@ -366,7 +366,7 @@ different from some other value:
   isnt $obj, $clone, "clone() produces a different object";
 
 For those grammatical pedants out there, there's an C<isn't()>
-function which is an alias of isnt().
+function which is an alias of C<isnt()>.
 
 =cut
 
@@ -383,12 +383,13 @@ sub isnt ($$;$) {
 }
 
 *isn't = \&isnt;
+# ' to unconfuse syntax higlighters
 
 =item B<like>
 
   like( $got, qr/expected/, $test_name );
 
-Similar to ok(), like() matches $got against the regex C<qr/expected/>.
+Similar to C<ok()>, C<like()> matches $got against the regex C<qr/expected/>.
 
 So this:
 
@@ -409,7 +410,7 @@ currently not supported):
 
 Regex options may be placed on the end (C<'/expected/i'>).
 
-Its advantages over ok() are similar to that of is() and isnt().  Better
+Its advantages over C<ok()> are similar to that of C<is()> and C<isnt()>.  Better
 diagnostics on failure.
 
 =cut
@@ -424,7 +425,7 @@ sub like ($$;$) {
 
   unlike( $got, qr/expected/, $test_name );
 
-Works exactly as like(), only it checks if $got B<does not> match the
+Works exactly as C<like()>, only it checks if $got B<does not> match the
 given pattern.
 
 =cut
@@ -453,7 +454,7 @@ passes if the comparison is true and fails otherwise.
     cmp_ok( $got, '&&', $expected, 'this && that' );
     ...etc...
 
-Its advantage over ok() is when the test fails you'll know what $got
+Its advantage over C<ok()> is when the test fails you'll know what $got
 and $expected were:
 
     not ok 1
@@ -463,7 +464,7 @@ and $expected were:
     #     undef
 
 It's also useful in those cases where you are comparing numbers and
-is()'s use of C<eq> will interfere:
+C<is()>'s use of C<eq> will interfere:
 
     cmp_ok( $big_hairy_number, '==', $another_big_hairy_number );
 
@@ -501,7 +502,7 @@ is almost exactly like saying:
 only without all the typing and with a better interface.  Handy for
 quickly testing an interface.
 
-No matter how many @methods you check, a single can_ok() call counts
+No matter how many @methods you check, a single C<can_ok()> call counts
 as one test.  If you desire otherwise, use:
 
     foreach my $meth (@methods) {
@@ -663,7 +664,7 @@ WHOA
   my $obj = new_ok( $class => \@args, $object_name );
 
 A convenience function which combines creating an object and calling
-isa_ok() on that object.
+C<isa_ok()> on that object.
 
 It is basically equivalent to:
 
@@ -672,7 +673,7 @@ It is basically equivalent to:
 
 If @args is not given, an empty list will be used.
 
-This function only works on new() and it assumes new() will return
+This function only works on C<new()> and it assumes C<new()> will return
 just a single object which isa C<$class>.
 
 =cut
@@ -704,7 +705,7 @@ sub new_ok {
 
     subtest $name => \&code;
 
-subtest() runs the &code as its own little test with its own plan and
+C<subtest()> 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.
 
@@ -734,7 +735,7 @@ This would produce.
   ok 2 - An example subtest
   ok 3 - Third test
 
-A subtest may call "skip_all".  No tests will be run, but the subtest is
+A subtest may call C<skip_all>.  No tests will be run, but the subtest is
 considered a skip.
 
   subtest 'skippy' => sub {
@@ -779,9 +780,9 @@ sub subtest {
 
 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 ok().  In this case, you can simply use pass() (to
+wedge into an C<ok()>.  In this case, you can simply use C<pass()> (to
 declare the test ok) or fail (for not ok).  They are synonyms for
-ok(1) and ok(0).
+C<ok(1)> and C<ok(0)>.
 
 Use these very, very, very sparingly.
 
@@ -896,7 +897,7 @@ If you just want to test a module can be loaded, use C<require_ok>.
 If you just want to load a module in a test, we recommend simply using
 C<use> directly.  It will cause the test to stop.
 
-It's recommended that you run use_ok() inside a BEGIN block so its
+It's recommended that you run C<use_ok()> inside a BEGIN block so its
 functions are exported at compile-time and prototypes are properly
 honored.
 
@@ -1017,16 +1018,16 @@ B<NOTE> I'm not quite sure what will happen with filehandles.
 
   is_deeply( $got, $expected, $test_name );
 
-Similar to is(), except that if $got and $expected are references, it
+Similar to C<is()>, except that if $got and $expected 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.
 
-is_deeply() compares the dereferenced values of references, the
+C<is_deeply()> 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".
 
-is_deeply() currently has very limited handling of function reference
+C<is_deeply()> 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.
 
@@ -1185,7 +1186,7 @@ interfere with the test.
 
   note(@diagnostic_message);
 
-Like diag(), except the message will not be seen when the test is run
+Like C<diag()>, 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.
 
 Handy for putting in notes which might be useful for debugging, but
@@ -1232,7 +1233,7 @@ sub explain {
 
 Sometimes running a test under certain conditions will cause the
 test script to die.  A certain function or method isn't implemented
-(such as fork() on MacOS), some resource isn't available (like a 
+(such as C<fork()> 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).
@@ -1337,7 +1338,7 @@ because you haven't fixed a bug or haven't finished a new feature:
 
 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.
+they are "todo".  L<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.
@@ -1366,7 +1367,7 @@ inside an C<eval BLOCK> with and using C<alarm>.  In these extreme
 cases you have no choice but to skip over the broken tests entirely.
 
 The syntax and behavior is similar to a C<SKIP: BLOCK> except the
-tests will be marked as failing but todo.  Test::Harness will
+tests will be marked as failing but todo.  L<Test::Harness> will
 interpret them as passing.
 
 =cut
@@ -1394,7 +1395,7 @@ sub todo_skip {
 
 B<If it's something the user might not be able to do>, use SKIP.
 This includes optional modules that aren't installed, running under
-an OS that doesn't have some feature (like fork() or symlinks), or maybe
+an OS that doesn't have some feature (like C<fork()> or symlinks), or maybe
 you need an Internet connection and one isn't available.
 
 B<If it's something the programmer hasn't done yet>, use TODO.  This
@@ -1440,11 +1441,11 @@ sub BAIL_OUT {
 
 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 is_deeply() existed
+out what went wrong.  They were written before C<is_deeply()> existed
 because I couldn't figure out how to display a useful diff of two
 arbitrary data structures.
 
-These functions are usually used inside an ok().
+These functions are usually used inside an C<ok()>.
 
     ok( eq_array(\@got, \@expected) );
 
@@ -1649,7 +1650,7 @@ sub _eq_hash {
 
   my $is_eq = eq_set(\@got, \@expected);
 
-Similar to eq_array(), except the order of the elements is B<not>
+Similar to C<eq_array()>, except the order of the elements is B<not>
 important.  This is a deep check, but the irrelevancy of order only
 applies to the top level.
 
@@ -1662,7 +1663,7 @@ Is better written:
 B<NOTE> By historical accident, this is not a true set comparison.
 While the order of elements does not matter, duplicate elements do.
 
-B<NOTE> eq_set() does not know how to deal with references at the top
+B<NOTE> C<eq_set()> does not know how to deal with references at the top
 level.  The following is an example of a comparison which might not work:
 
     eq_set([\1, \2], [\2, \1]);
@@ -1700,13 +1701,13 @@ sub eq_set {
 =head2 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,
+Test::More is built on top of L<Test::Builder> which provides a single,
 unified backend for any test library to use.  This means two test
-libraries which both use Test::Builder B<can be used together in the
+libraries which both use <Test::Builder> B<can> be used together in the
 same program>.
 
 If you simply want to do a little tweaking of how the tests behave,
-you can access the underlying Test::Builder object like so:
+you can access the underlying L<Test::Builder> object like so:
 
 =over 4
 
@@ -1714,7 +1715,7 @@ you can access the underlying Test::Builder object like so:
 
     my $test_builder = Test::More->builder;
 
-Returns the Test::Builder object underlying Test::More for you to play
+Returns the L<Test::Builder> object underlying Test::More for you to play
 with.
 
 
@@ -1723,10 +1724,10 @@ with.
 
 =head1 EXIT CODES
 
-If all your tests passed, Test::Builder will exit with zero (which is
+If all your tests passed, L<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 be considered failures.  If no tests were ever run L<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.
@@ -1785,8 +1786,9 @@ There is a full version history in the Changes file, and the Test::More versions
 =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 C<binmode
-STDOUT, ":utf8"> will not fix it.  Test::Builder (which powers
+might get a "Wide character in print" warning.  Using
+C<< binmode STDOUT, ":utf8" >> will not fix it.
+L<Test::Builder> (which powers
 Test::More) duplicates STDOUT and STDERR.  So any changes to them,
 including changing their output disciplines, will not be seem by
 Test::More.
@@ -1798,7 +1800,7 @@ as possible and before Test::More (or any other Test module) loads.
     use Test::More;
 
 A more direct work around is to change the filehandles used by
-Test::Builder.
+L<Test::Builder>.
 
     my $builder = Test::More->builder;
     binmode $builder->output,         ":encoding(utf8)";
@@ -1808,14 +1810,14 @@ Test::Builder.
 
 =item Overloaded objects
 
-String overloaded objects are compared B<as strings> (or in cmp_ok()'s
+String overloaded objects are compared B<as strings> (or in C<cmp_ok()>'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.
 
-However, it does mean that functions like is_deeply() cannot be used to
+However, it does mean that functions like C<is_deeply()> cannot be used to
 test the internals of string overloaded objects.  In this case I would
 suggest L<Test::Deep> which contains more flexible testing functions for
 complex data structures.
@@ -1823,7 +1825,7 @@ complex data structures.
 
 =item Threads
 
-Test::More will only be aware of threads if "use threads" has been done
+Test::More will only be aware of threads if C<use threads> has been done
 I<before> Test::More is loaded.  This is ok:
 
     use threads;
@@ -1841,9 +1843,9 @@ This may cause problems:
 
 =head1 HISTORY
 
-This is a case of convergent evolution with Joshua Pritikin's Test
+This is a case of convergent evolution with Joshua Pritikin's L<Test>
 module.  I was largely unaware of its existence when I'd first
-written my own ok() routines.  This module exists because I can't
+written my own C<ok()> 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).
 
@@ -1856,18 +1858,29 @@ magic side-effects are kept to a minimum.  WYSIWYG.
 
 =head1 SEE ALSO
 
+=head2
+
+=head2 ALTERNATIVES
+
 L<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).
 
-L<Test::Harness> is the test runner and output interpreter for Perl.
-It's the thing that powers C<make test> and where the C<prove> utility
-comes from.
-
 L<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.
 
+=head2 TESTING FRAMEWORKS
+
+L<Fennec> The Fennec framework is a testers toolbox. It uses L<Test::Builder>
+under the hood. It brings enhancements for forking, defining state, and
+mocking. Fennec enhances several modules to work better together than they
+would if you loaded them individually on your own.
+
+L<Fennec::Declare> Provides enhanced (L<Devel::Declare>) syntax for Fennec.
+
+=head2 ADDITIONAL LIBRARIES
+
 L<Test::Differences> for more ways to test complex data structures.
 And it plays well with Test::More.
 
@@ -1877,8 +1890,22 @@ L<Test::Deep> gives you more powerful complex data structure testing.
 
 L<Test::Inline> shows the idea of embedded testing.
 
+L<Mock::Quick> The ultimate mocking library. Easily spawn objects defined on
+the fly. Can also override, block, or reimplement packages as needed.
+
+L<Test::FixtureBuilder> Quickly define fixture data for unit tests.
+
+=head2 OTHER COMPONENTS
+
+L<Test::Harness> is the test runner and output interpreter for Perl.
+It's the thing that powers C<make test> and where the C<prove> utility
+comes from.
+
+=head2 BUNDLES
+
 L<Bundle::Test> installs a whole bunch of useful test modules.
 
+L<Test::Most> Most commonly needed test functions and features.
 
 =head1 AUTHORS
 
index 8d123b4..68110d5 100644 (file)
@@ -4,7 +4,7 @@ use 5.006;
 
 use strict;
 
-our $VERSION = '1.001003';
+our $VERSION = '1.001006';
 $VERSION = eval $VERSION;    ## no critic (BuiltinFunctions::ProhibitStringyEval)
 
 use Test::Builder::Module 0.99;
@@ -26,7 +26,7 @@ Test::Simple - Basic utilities for writing tests.
 
 =head1 DESCRIPTION
 
-** If you are unfamiliar with testing B<read Test::Tutorial> first! **
+** If you are unfamiliar with testing B<read L<Test::Tutorial> first!> **
 
 This is an extremely simple, extremely basic module for writing tests
 suitable for CPAN modules and other pursuits.  If you wish to do more
@@ -35,7 +35,7 @@ for this one).
 
 The basic unit of Perl testing is the ok.  For each thing you want to
 test your program will print out an "ok" or "not ok" to indicate pass
-or fail.  You do this with the ok() function (see below).
+or fail.  You do this with the C<ok()> function (see below).
 
 The only other constraint is you must pre-declare how many tests you
 plan to run.  This is in case something goes horribly wrong during the
@@ -54,10 +54,10 @@ You must have a plan.
   ok( $foo eq $bar, $name );
   ok( $foo eq $bar );
 
-ok() is given an expression (in this case C<$foo eq $bar>).  If it's
+C<ok()> is given an expression (in this case C<$foo eq $bar>).  If it's
 true, the test passed.  If it's false, it didn't.  That's about it.
 
-ok() prints out either "ok" or "not ok" along with a test number (it
+C<ok()> prints out either "ok" or "not ok" along with a test number (it
 keeps track of that for you).
 
   # This produces "ok 1 - Hell not yet frozen over" (or not ok)
@@ -84,7 +84,7 @@ sub ok ($;$) {    ## no critic (Subroutines::ProhibitSubroutinePrototypes)
 
 Test::Simple will start by printing number of tests run in the form
 "1..M" (so "1..5" means you're going to run 5 tests).  This strange
-format lets Test::Harness know how many tests you plan on running in
+format lets L<Test::Harness> know how many tests you plan on running in
 case something goes horribly wrong.
 
 If all your tests passed, Test::Simple will exit with zero (which is
@@ -185,13 +185,13 @@ he wasn't in Tony's kitchen).  This is it.
 =item L<Test::More>
 
 More testing functions!  Once you outgrow Test::Simple, look at
-Test::More.  Test::Simple is 100% forward compatible with Test::More
-(i.e. you can just use Test::More instead of Test::Simple in your
+L<Test::More>.  Test::Simple is 100% forward compatible with L<Test::More>
+(i.e. you can just use L<Test::More> instead of Test::Simple in your
 programs and things will still work).
 
 =back
 
-Look in Test::More's SEE ALSO for more testing modules.
+Look in L<Test::More>'s SEE ALSO for more testing modules.
 
 
 =head1 AUTHORS
index 8badf38..a71a9c1 100644 (file)
@@ -90,7 +90,7 @@ along. [2]
 
 This is the hardest part of testing, where do you start?  People often get
 overwhelmed at the apparent enormity of the task of testing a whole module.
-The best place to start is at the beginning.  C<Date::ICal> is an
+The best place to start is at the beginning.  L<Date::ICal> is an
 object-oriented module, and that means you start by making an object.  Test
 C<new()>.
 
@@ -176,18 +176,18 @@ Run that and you get:
     ok 8 -   year()
     # Looks like you failed 1 tests of 8.
 
-Whoops, a failure! [4] C<Test::Simple> helpfully lets us know on what line the
+Whoops, a failure! [4] L<Test::Simple> helpfully lets us know on what line the
 failure occurred, but not much else.  We were supposed to get 17, but we
 didn't.  What did we get??  Dunno.  You could re-run the test in the debugger
 or throw in some print statements to find out.
 
-Instead, switch from L<Test::Simple> to L<Test::More>.  C<Test::More>
-does everything C<Test::Simple> does, and more!  In fact, C<Test::More> does
-things I<exactly> the way C<Test::Simple> does.  You can literally swap
-C<Test::Simple> out and put C<Test::More> in its place.  That's just what
+Instead, switch from L<Test::Simple> to L<Test::More>.  L<Test::More>
+does everything L<Test::Simple> does, and more!  In fact, L<Test::More> does
+things I<exactly> the way L<Test::Simple> does.  You can literally swap
+L<Test::Simple> out and put L<Test::More> in its place.  That's just what
 we're going to do.
 
-C<Test::More> does more than C<Test::Simple>.  The most important difference at
+L<Test::More> does more than L<Test::Simple>.  The most important difference at
 this point is it provides more informative ways to say "ok".  Although you can
 write almost any test with a generic C<ok()>, it can't tell you what went
 wrong.  The C<is()> function lets us declare that something is supposed to be
@@ -210,7 +210,7 @@ the same as something else:
     is( $ical->month,   10,       '  month()' );
     is( $ical->year,    1964,     '  year()'  );
 
-"Is C<$ical-E<gt>sec> 47?"  "Is C<$ical-E<gt>min> 12?"  With C<is()> in place,
+"Is C<< $ical->sec >> 47?"  "Is C<< $ical->min >> 12?"  With C<is()> in place,
 you get more information:
 
     1..8
@@ -227,7 +227,7 @@ you get more information:
     ok 8 -   year()
     # Looks like you failed 1 tests of 8.
 
-Aha. C<$ical-E<gt>day> returned 16, but we expected 17.  A
+Aha. C<< $ical->day >> returned 16, but we expected 17.  A
 quick check shows that the code is working fine, we made a mistake
 when writing the tests.  Change it to:
 
@@ -297,7 +297,7 @@ Now we can test bunches of dates by just adding them to
 C<%ICal_Dates>.  Now that it's less work to test with more dates, you'll
 be inclined to just throw more in as you think of them.
 Only problem is, every time we add to that we have to keep adjusting
-the C<use Test::More tests =E<gt> ##> line.  That can rapidly get
+the L<< use Test::More tests => ## >> line.  That can rapidly get
 annoying.  There are ways to make this work better.
 
 First, we can calculate the plan dynamically using the C<plan()>
@@ -324,10 +324,10 @@ running some tests, don't know how many. [6]
 
     done_testing();   # reached the end safely
 
-If you don't specify a plan, C<Test::More> expects to see C<done_testing()>
+If you don't specify a plan, L<Test::More> expects to see C<done_testing()>
 before your program exits. It will warn you if you forget it. You can give
 C<done_testing()> an optional number of tests you expected to run, and if the
-number ran differs, C<Test::More> will give you another kind of warning.
+number ran differs, L<Test::More> will give you another kind of warning.
 
 
 =head2 Informative names
@@ -417,7 +417,7 @@ the test.
 A little bit of magic happens here.  When running on anything but MacOS, all
 the tests run normally.  But when on MacOS, C<skip()> causes the entire
 contents of the SKIP block to be jumped over.  It never runs.  Instead,
-C<skip()> prints special output that tells C<Test::Harness> that the tests have
+C<skip()> prints special output that tells L<Test::Harness> that the tests have
 been skipped.
 
     1..7
@@ -446,7 +446,7 @@ The tests are wholly and completely skipped. [10]  This will work.
 
 =head2 Todo tests
 
-While thumbing through the C<Date::ICal> man page, I came across this:
+While thumbing through the L<Date::ICal> man page, I came across this:
 
    ical
 
@@ -497,12 +497,12 @@ Now when you run, it's a little different:
     #          got: '20010822T201551Z'
     #     expected: '20201231Z'
 
-C<Test::More> doesn't say "Looks like you failed 1 tests of 1".  That '#
-TODO' tells C<Test::Harness> "this is supposed to fail" and it treats a
+L<Test::More> doesn't say "Looks like you failed 1 tests of 1".  That '#
+TODO' tells L<Test::Harness> "this is supposed to fail" and it treats a
 failure as a successful test.  You can write tests even before
 you've fixed the underlying code.
 
-If a TODO test passes, C<Test::Harness> will report it "UNEXPECTEDLY
+If a TODO test passes, L<Test::Harness> will report it "UNEXPECTEDLY
 SUCCEEDED".  When that happens, remove the TODO block with C<local $TODO> and
 turn it into a real test.
 
@@ -517,7 +517,7 @@ in mind, it's very important to ensure your module works under taint
 mode.
 
 It's very simple to have your tests run under taint mode.  Just throw
-a C<-T> into the C<#!> line.  C<Test::Harness> will read the switches
+a C<-T> into the C<#!> line.  L<Test::Harness> will read the switches
 in C<#!> and use them to run your tests.
 
     #!/usr/bin/perl -Tw
@@ -558,7 +558,7 @@ We'll get to testing the contents of lists later.
 
 But what happens if your test program dies halfway through?!  Since we
 didn't say how many tests we're going to run, how can we know it
-failed?  No problem, C<Test::More> employs some magic to catch that death
+failed?  No problem, L<Test::More> employs some magic to catch that death
 and turn the test into a failure, even if every test passed up to that
 point.
 
index 0657a06..cf9f907 100644 (file)
@@ -1,4 +1,5 @@
 #!/usr/bin/perl -w
+use Config; # To prevent conflict with some strawberry-portable versions
 
 BEGIN {
     if( $ENV{PERL_CORE} ) {
index 5271323..8ae26ba 100644 (file)
@@ -3,6 +3,17 @@
 use strict;
 use Test::Builder;
 
+BEGIN {
+    if( $ENV{PERL_CORE} ) {
+        chdir 't';
+        @INC = ( '../lib', 'lib' );
+    }
+    else {
+        unshift @INC, 't/lib';
+    }
+}
+use Test::Builder::NoOutput;
+
 my $tb = Test::Builder->new;
 
 $tb->ok( !eval { $tb->subtest() } );
@@ -11,4 +22,12 @@ $tb->like( $@, qr/^\Qsubtest()'s second argument must be a code ref/ );
 $tb->ok( !eval { $tb->subtest("foo") } );
 $tb->like( $@, qr/^\Qsubtest()'s second argument must be a code ref/ );
 
+$tb->subtest('Arg passing', sub {
+    my $foo = shift;
+    my $child = Test::Builder->new;
+    $child->is_eq($foo, 'foo');
+    $child->done_testing;
+    $child->finalize;
+}, 'foo');
+
 $tb->done_testing();