Permalink
Browse files

Merge branch 'master' into Test-Builder1.5

The new t/subtest/wstat.t and t/subtest/bail_out.t tests are failing.
Going to work on that next.

Conflicts:
	.gitignore
	Changes
	MANIFEST
	MANIFEST.SKIP
	Makefile.PL
	lib/Test/Builder.pm
	lib/Test/Builder/Module.pm
	lib/Test/Builder/Tester.pm
	lib/Test/Builder/Tester/Color.pm
	lib/Test/More.pm
	lib/Test/Simple.pm
	t/lib/Test/Builder/NoOutput.pm
	t/subtest/basic.t
  • Loading branch information...
2 parents 7d47f1e + fff6727 commit f3ec85ada357f4b079b02071c7457c7530363bda @schwern schwern committed Nov 16, 2011
View
@@ -100,6 +100,29 @@ See README and version control log for Test::Builder2 changes.
Very incomplete.
+0.98_01 Tue Nov 8 17:07:58 PST 2011
+ Bug Fixes
+ * BAIL_OUT works inside a subtest. (Larry Leszczynski) [github #138]
+ * subtests now work with threads turned on. [github #145]
+
+ Feature Changes
+ * use_ok() will now apply lexical effects. [rt.cpan.org 67538]
+ (Father Chrysostomos)
+
+ Misc
+ * Test::More, Test::Simple and Test::Builder::Module now require
+ a minimum version of Test::Builder. This avoids Test::More and
+ Test::Builder from getting out of sync. [github #89]
+
+
+0.98 Wed, 23 Feb 2011 14:38:02 +1100
+ Bug Fixes
+ * subtest() should not fail if $? is non-zero. (Aaron Crane)
+
+ Docs
+ * The behavior of is() and undef has been documented. (Pedro Melo)
+
+
0.97_01 Fri Aug 27 22:50:30 PDT 2010
Test Fixes
* Adapted the tests for the new Perl 5.14 regex stringification.
View
@@ -248,6 +248,7 @@ t/skip.t
t/skip_before_plan.t
t/skipall.t
t/subtest/args.t
+t/subtest/bail_out.t
t/subtest/basic.t
t/subtest/default.t
t/subtest/die.t
@@ -259,6 +260,9 @@ t/subtest/line_numbers.t
t/subtest/plan.t
t/subtest/predicate.t
t/subtest/todo.t
+t/subtest/threads.t
+t/subtest/todo.t
+t/subtest/wstat.t
t/TB1vsTB2.t
t/tbm_doesnt_set_exported_to.t
t/test.pl
View
@@ -75,3 +75,4 @@
# Don't distribute our distribution tools
^dist/
+
View
@@ -124,15 +124,20 @@ MAKE
$make =~ s{\s+\z}{\n};
my @perls = qw(
- perl5.8.8
- perl5.8.9
- perl5.10.0
+ perl5.14.1
+ perl5.12.4
+ perl5.12.3
perl5.10.1
- perl5.12.0
- perl5.12.1
+ perl5.10.0
+ perl5.8.9
+ perl5.8.8
);
for my $perl (@perls) {
+ if( !`which $perl` ) {
+ print STDERR "Missing $perl";
+ next;
+ }
$make .= sprintf <<'END', $perl;
cd $(DISTVNAME) && $(MAKE) clean && %s Makefile.PL && PERL_RELEASING=0 $(MAKE) test $(PASTHRU)
END
View
@@ -299,6 +299,7 @@ sub counter {
return $counter;
}
+
=back
=head2 Setting up tests
@@ -448,7 +449,7 @@ Or to plan a variable number of tests:
for my $test (@tests) {
$Test->ok($test);
}
- $Test->done_testing(@tests);
+ $Test->done_testing(scalar @tests);
=cut
@@ -746,13 +747,17 @@ sub _is_dualvar {
Like Test::More's C<is()>. Checks if C<$got eq $expected>. This is the
string version.
+C<undef> only ever matches another C<undef>.
+
=item B<is_num>
$Test->is_num($got, $expected, $name);
Like Test::More's C<is()>. Checks if C<$got == $expected>. This is the
numeric version.
+C<undef> only ever matches another C<undef>.
+
=cut
sub is_eq {
@@ -2,7 +2,7 @@ package Test::Builder::Module;
use strict;
-use Test::Builder;
+use Test::Builder 0.98;
require Exporter;
our @ISA = qw(Exporter);
@@ -1,7 +1,7 @@
package Test::Builder::Tester;
use strict;
-our $VERSION = "1.21_07";
+our $VERSION = "1.22_07";
use Test::Builder;
use Symbol;
@@ -1,7 +1,7 @@
package Test::Builder::Tester::Color;
use strict;
-our $VERSION = "1.21_07";
+our $VERSION = "1.22_07";
require Test::Builder::Tester;
View
@@ -10,7 +10,7 @@ issues with Perl.
=head2 Is there any tutorial on testing?
-Test::Tutorial
+L<Test::Tutorial>
=head2 Are there any modules for testing?
@@ -20,23 +20,23 @@ Then go onto L<http://search.cpan.org> and search for "Test".
=head2 Are there any modules for testing web pages/CGI programs?
-Test::WWW::Mechanize, Test::WWW::Selenium
+L<Test::WWW::Mechanize>, L<Test::WWW::Selenium>
=head2 Are there any modules for testing external programs?
-Test::Cmd
+L<Test::Cmd>
=head2 Can you do xUnit/JUnit style testing in Perl?
-Yes, Test::Class allows you to write test methods while continuing to
+Yes, L<Test::Class> allows you to write test methods while continuing to
use all the usual CPAN testing modules. It is the best and most
perlish way to do xUnit style testing.
-Test::Unit is a more direct port of XUnit to Perl, but it does not use
+L<Test::Unit> is a more direct port of XUnit to Perl, but it does not use
the Perl conventions and does not play well with other CPAN testing
modules. As of this writing, it is abandoned. B<Do not use>.
-The Test::Inline (aka Pod::Tests) is worth mentioning as it allows you to
+The L<Test::Inline> (aka L<Pod::Tests>) is worth mentioning as it allows you to
put tests into the POD in the same file as the code.
@@ -109,24 +109,67 @@ all.
=head2 How do I measure the coverage of my test suite?
-Devel::Cover
+L<Devel::Cover>
=head2 How do I get tests to run in a certain order?
Tests run in alphabetical order, so simply name your test files in the order
you want them to run. Numbering your test files works, too.
-To achieve a specific order, try Test::Manifest.
+ t/00_compile.t
+ t/01_config.t
+ t/zz_teardown.t
+
+0 runs first, z runs last.
+
+To achieve a specific order, try L<Test::Manifest>.
+
+Typically you do B<not> want your tests to require being run in a
+certain order, but it can be useful to do a compile check first or to
+run the tests on a very basic module before everything else. This
+gives you early information if a basic module fails which will bring
+everything else down.
+
+Another use is if you have a suite wide setup/teardown, such as
+creating and delete a large test database, which may be too
+expensive to do for every test.
+
+We recommend B<against> numbering every test file. For most files
+this ordering will be arbitrary and the leading number obscures the
+real name of the file. See L<What should I name my test files?> for
+more information.
+
=head2 What should I name my tests?
+=head2 What should I name my test files?
+
+A test filename serves three purposes:
+
+Most importantly, it serves to identify what is being tested. Each
+test file should test a clear piece of functionality. This could be
+at single class, a single method, even a single bug.
+
+The order in which tests are run is usually dictated by the filename.
+See L<How do I get tests to run in a certain order?> for details.
+
+Finally, the grouping of tests into common bits of functionality can
+be achieved by directory and filenames. For example, all the tests
+for Test::Builder are in the F<t/Builder/> directory.
+
+As an example, F<t/Builder/reset.t> contains the tests for
+C<< Test::Builder->reset >>. F<t/00compile.t> checks that everything
+compiles, and it will run first. F<t/dont_overwrite_die_handler.t>
+checks that we don't overwrite the C<<$SIG{__DIE__}>> handler.
+
+
=head2 How do I deal with tests that sometimes pass and sometimes fail?
=head2 How do I test with a database/network/server that the user may or may not have?
=head2 What's a good way to test lists?
-is_deeply() from Test::More as well as Test::Deep.
+C<is_deeply()> from L<Test::More> as well as L<Test::Deep>.
=head2 Is there such a thing as untestable code?
@@ -149,19 +192,19 @@ Even a random number generator can be tested.
=head2 How do I check the right warnings are issued?
-Test::Warn
+L<Test::Warn>
=head2 How do I test code that prints?
-Test::Output
+L<Test::Output>
=head2 I want to test that my code dies when I do X
-Test::Exception
+L<Test::Exception>
=head2 I want to print out more diagnostic info on failure.
-ok(...) || diag "...";
+C<ok(...) || diag "...";>
=head2 How can I simulate failures to make sure that my code does the Right Thing in the face of them?
@@ -256,9 +299,38 @@ say C<use lib 't/lib'>.
=head2 Why do I need more than ok?
+Since every test can be reduced to checking if a statement is true,
+ok() can test everything. But ok() doesn't tell you why the test
+failed. For that you need to tell the test more... which is why
+you need L<Test::More>.
+
+ ok $pirate->name eq "Roberts", "person's name";
+
+ not ok 1 - person's name
+ # Failed test at pirates.t line 23.
+
+If the above fails, you don't know what C<< $person->name >> returned.
+You have to go in and add a C<diag> call. This is time consuming. If
+it's a heisenbug, it might not fail again! If it's a user reporting a
+test failure, they might not be bothered to hack the tests to give you
+more information.
+
+ is $person->name, "Roberts", "person's name";
+
+ not ok 1 - person's name
+ # Failed test at pirates.t line 23.
+ # got: 'Wesley'
+ # expected: 'Roberts'
+
+Using C<is> from L<Test::More> you now know what value you got and
+what value you expected.
+
+The most useful functions in Test::More are is, like and is_deeply.
+
+
=head2 What's wrong with C<print $test ? "ok" : "not ok">?
-=head2 How do I check for an infinite loop
+=head2 How do I check for an infinite loop?
On Mon, Mar 18, 2002 at 03:57:55AM -0500, Mark-Jason Dominus wrote:
>
@@ -275,7 +347,8 @@ On Mon, Mar 18, 2002 at 03:57:55AM -0500, Mark-Jason Dominus wrote:
=head2 How do I use the comparison functions of a testing module without it being a test?
-Any testing function based on Test::Builder, most are, can be quieted so it does not do any testing. It simply returns true or false. Use the following code...
+Any testing function based on Test::Builder, most are, can be quieted so it does
+not do any testing. It simply returns true or false. Use the following code...
use Test::More; # or any testing module
Oops, something went wrong.

0 comments on commit f3ec85a

Please sign in to comment.