@@ -1,3 +1,27 @@
+1.001008 Wed Oct 15 20:10:22:00 PST 2014
+ * Updated Changes file
+
+1.001007 Wed Oct 15 16:37:11:00 PST 2014
+ * Fix subtest name when skip_all is used
+
+1.001006 Tue Sep 2 14:39:05:00 PST 2014
+ * Reverted change that is now part of alpha branch
+
+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
+
1.001003 Fri Mar 21 21:12:32 PST 2014
* Doc updates for maintainer change
@@ -17,6 +17,7 @@ MANIFEST.SKIP
README
t/00compile.t
t/00test_harness_check.t
+t/478-cmp_ok_hash.t
t/bad_plan.t
t/bail_out.t
t/BEGIN_require_ok.t
@@ -4,7 +4,7 @@
"Michael G Schwern <schwern@pobox.com>"
],
"dynamic_config" : 1,
- "generated_by" : "ExtUtils::MakeMaker version 6.92, CPAN::Meta::Converter version 2.120921",
+ "generated_by" : "ExtUtils::MakeMaker version 6.98, CPAN::Meta::Converter version 2.142060",
"license" : [
"perl_5"
],
@@ -52,5 +52,5 @@
},
"x_MailingList" : "http://lists.perl.org/list/perl-qa.html"
},
- "version" : "1.001003"
+ "version" : "1.001009"
}
@@ -3,28 +3,28 @@ abstract: 'Basic utilities for writing tests.'
author:
- 'Michael G Schwern <schwern@pobox.com>'
build_requires:
- ExtUtils::MakeMaker: 0
+ ExtUtils::MakeMaker: '0'
configure_requires:
- ExtUtils::MakeMaker: 0
+ ExtUtils::MakeMaker: '0'
dynamic_config: 1
-generated_by: 'ExtUtils::MakeMaker version 6.92, CPAN::Meta::Converter version 2.120921'
+generated_by: 'ExtUtils::MakeMaker version 6.98, CPAN::Meta::Converter version 2.142060'
license: perl
meta-spec:
url: http://module-build.sourceforge.net/META-spec-v1.4.html
- version: 1.4
+ version: '1.4'
name: Test-Simple
no_index:
directory:
- t
- inc
requires:
- Scalar::Util: 1.13
- Test::Harness: 2.03
- perl: 5.006
+ Scalar::Util: '1.13'
+ Test::Harness: '2.03'
+ perl: '5.006'
resources:
+ MailingList: http://lists.perl.org/list/perl-qa.html
bugtracker: http://github.com/Test-More/test-more/issues/
homepage: http://github.com/Test-More/test-more/
license: http://dev.perl.org/licenses/
repository: http://github.com/Test-More/test-more/
- x_MailingList: http://lists.perl.org/list/perl-qa.html
-version: 1.001003
+version: '1.001009'
@@ -54,6 +54,7 @@ if ($mm_ver =~ /_/) { # dev version
my %Prereqs;
$Prereqs{'ExtUtils::MakeMaker'} = 6.27 if $^O eq 'MSWin32';
+my $install_dir = $] >= 5.006002 && $] < 5.012000 ? 'perl' : 'site';
WriteMakefile(
NAME => $PACKAGE,
@@ -70,8 +71,7 @@ WriteMakefile(
%Prereqs
},
- # Added to the core in 5.7.3 and also 5.6.2.
- INSTALLDIRS => $] >= 5.006002 ? 'perl' : 'site',
+ INSTALLDIRS => $install_dir,
test => {
TESTS => 't/*.t t/*/*.t',
@@ -7,11 +7,11 @@ Test::Builder::IO::Scalar - A copy of IO::Scalar for Test::Builder
=head1 DESCRIPTION
-This is a copy of IO::Scalar which ships with Test::Builder to
+This is a copy of L<IO::Scalar> which ships with L<Test::Builder> to
support scalar references as filehandles on Perl 5.6. Newer
-versions of Perl simply use C<<open()>>'s built in support.
+versions of Perl simply use C<open()>'s built in support.
-Test::Builder can not have dependencies on other modules without
+L<Test::Builder> can not have dependencies on other modules without
careful consideration, so its simply been copied into the distribution.
=head1 COPYRIGHT and LICENSE
@@ -38,7 +38,7 @@ use IO::Handle;
use 5.005;
### The package version, both in 1.23 style *and* usable by MakeMaker:
-$VERSION = "2.110";
+$VERSION = "2.111";
### Inheritance:
@ISA = qw(IO::Handle);
@@ -7,7 +7,7 @@ use Test::Builder 0.99;
require Exporter;
our @ISA = qw(Exporter);
-our $VERSION = '1.001003';
+our $VERSION = '1.001009';
$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;
@@ -1,7 +1,7 @@
package Test::Builder::Tester::Color;
use strict;
-our $VERSION = "1.23_002";
+our $VERSION = "1.24";
require Test::Builder::Tester;
@@ -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.
@@ -4,7 +4,7 @@ use 5.006;
use strict;
use warnings;
-our $VERSION = '1.001003';
+our $VERSION = '1.001009';
$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.
@@ -352,7 +355,7 @@ sub finalize {
$self->parent->{Child_Name} = undef;
unless ($self->{Bailed_Out}) {
if ( $self->{Skip_All} ) {
- $self->parent->skip($self->{Skip_All});
+ $self->parent->skip($self->{Skip_All}, $self->name);
}
elsif ( not @{ $self->{Test_Results} } ) {
$self->parent->ok( 0, sprintf q[No tests run for subtest "%s"], $self->name );
@@ -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);
@@ -1159,7 +1162,7 @@ sub cmp_ok {
$self->croak("$type is not a valid comparison operator in cmp_ok()");
}
- my $test;
+ my ($test, $succ);
my $error;
{
## no critic (BuiltinFunctions::ProhibitStringyEval)
@@ -1169,9 +1172,10 @@ sub cmp_ok {
my($pack, $file, $line) = $self->caller();
# This is so that warnings come out at the caller's level
- $test = eval qq[
+ $succ = eval qq[
#line $line "(eval in cmp_ok) $file"
-\$got $type \$expect;
+\$test = (\$got $type \$expect);
+1;
];
$error = $@;
}
@@ -1185,7 +1189,7 @@ sub cmp_ok {
? '_unoverload_num'
: '_unoverload_str';
- $self->diag(<<"END") if $error;
+ $self->diag(<<"END") unless $succ;
An error occurred while using $type:
------------------------------------
$error
@@ -1246,7 +1250,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.
@@ -1289,8 +1293,9 @@ Skips the current test, reporting C<$why>.
=cut
sub skip {
- my( $self, $why ) = @_;
+ my( $self, $why, $name ) = @_;
$why ||= '';
+ $name = '' unless defined $name;
$self->_unoverload_str( \$why );
lock( $self->{Curr_Test} );
@@ -1300,7 +1305,7 @@ sub skip {
{
'ok' => 1,
actual_ok => 1,
- name => '',
+ name => $name,
type => 'skip',
reason => $why,
}
@@ -2201,7 +2206,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 +2621,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 +2629,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
@@ -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.001009';
$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
@@ -4,7 +4,7 @@ use 5.006;
use strict;
-our $VERSION = '1.001003';
+our $VERSION = '1.001009';
$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
@@ -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.
@@ -0,0 +1,41 @@
+use strict;
+use warnings;
+use Test::More;
+
+
+my $want = 0;
+my $got = 0;
+
+cmp_ok($got, 'eq', $want, "Passes on correct comparison");
+
+my ($res, @ok, @diag, @warn);
+{
+ no warnings 'redefine';
+ local *Test::Builder::ok = sub {
+ my ($tb, $ok, $name) = @_;
+ push @ok => $ok;
+ return $ok;
+ };
+ local *Test::Builder::diag = sub {
+ my ($tb, @d) = @_;
+ push @diag => @d;
+ };
+ local $SIG{__WARN__} = sub {
+ push @warn => @_;
+ };
+ $res = cmp_ok($got, '#eq', $want, "You shall not pass!");
+}
+
+ok(!$res, "Did not pass");
+
+is(@ok, 1, "1 result");
+ok(!$ok[0], "result is false");
+
+# We only care that it mentions a syntax error.
+like(join("\n" => @diag), qr/syntax error at \(eval in cmp_ok\)/, "Syntax error");
+
+# We are not going to inspect the warning because it is not super predictable,
+# and changes with eval specifics.
+ok(@warn, "We got warnings");
+
+done_testing;
@@ -1,4 +1,5 @@
#!/usr/bin/perl -w
+use Config; # To prevent conflict with some strawberry-portable versions
BEGIN {
if( $ENV{PERL_CORE} ) {
@@ -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();