unlikely that nonportable additions to the Perl language will be
accepted.
+=item Is the implementation tested?
+
+Patches which change behaviour (fixing bugs or introducing new features)
+must include regression tests to verify that everything works as expected.
+Without tests provided by the original author, how can anyone else changing
+perl in the future be sure that they haven't unwittingly broken the behaviour
+the patch implements? And without tests, how can the patch's author be
+confident that his/her hard work put into the patch won't be accidentally
+thrown away by someone in the future?
+
=item Is there enough documentation?
Patches without documentation are probably ill-thought out or
incomplete. Nothing can be added without documentation, so submitting
a patch for the appropriate manpages as well as the source code is
-always a good idea. If appropriate, patches should add to the test
-suite as well.
+always a good idea.
=item Is there another way to do it?
Unicode strings.
t/op/pack.t has a sensible ok() function, but if it didn't we could
-write one easily.
-
- my $test = 1;
- sub ok {
- my($ok, $name) = @_;
+use the one from t/test.pl.
- # You have to do it this way or VMS will get confused.
- print $ok ? "ok $test - $name\n" : "not ok $test - $name\n";
-
- printf "# Failed test at line %d\n", (caller)[2] unless $ok;
-
- $test++;
- return $ok;
- }
+ require './test.pl';
+ plan( tests => 159 );
so instead of this:
print 'not ' unless "1.20.300.4000" eq sprintf "%vd", pack("U*",1,20,300,4000);
print "ok $test\n"; $test++;
-we can write the (somewhat) more sensible:
+we can write the more sensible (see L<Test::More> for a full
+explanation of is() and other testing functions).
- ok( "1.20.300.4000" eq sprintf "%vd", pack("U*",1,20,300,4000),
+ is( "1.20.300.4000", sprintf "%vd", pack("U*",1,20,300,4000),
"U* produces unicode" );
Now we'll test that we got that space-at-the-beginning business right:
- ok( "1.20.300.4000" eq sprintf "%vd", pack(" U*",1,20,300,4000),
+ is( "1.20.300.4000", sprintf "%vd", pack(" U*",1,20,300,4000),
" with spaces at the beginning" );
And finally we'll test that we don't make Unicode strings if C<U> is B<not>
the first active format:
- ok( v1.20.300.4000 ne sprintf "%vd", pack("C0U*",1,20,300,4000),
+ isnt( v1.20.300.4000, sprintf "%vd", pack("C0U*",1,20,300,4000),
"U* not first isn't unicode" );
-Mustn't forget to change the number of tests which appears at the top, or
-else the automated tester will get confused:
+Mustn't forget to change the number of tests which appears at the top,
+or else the automated tester will get confused. This will either look
+like this:
+
+ print "1..156\n";
- -print "1..156\n";
- +print "1..159\n";
+or this:
+
+ plan( tests => 156 );
We now compile up Perl, and run it through the test suite. Our new
tests pass, hooray!
to explore all boundary conditions that your new function is expected
to handle. If your new function is used only by one module (e.g. toke),
then it should probably be named S_your_function (for static); on the
-other hand, if you expect it to accessable from other functions in
+other hand, if you expect it to accessible from other functions in
Perl, you should name it Perl_your_function. See L<perlguts/Internal Functions>
for more details.
Test on as many platforms as you can find. Test as many perl
Configure options as you can (e.g. MULTIPLICITY). If you have
profiling or memory tools, see L<EXTERNAL TOOLS FOR DEBUGGING PERL>
-below for how to use them to futher test your code. Remember that
+below for how to use them to further test your code. Remember that
most of the people on P5P are doing this on their own time and
don't have the time to debug your code.
=item F<t/cmd/>
These test the basic control structures, C<if/else>, C<while>,
-subroutines, etc...
+subroutines, etc.
=item F<t/comp/>
"ok/not ok" run through Test::Harness, but there are a few special
considerations.
-For most libraries and extensions, you'll want to use the Test::More
-library rather than rolling your own test functions. If a module test
-doesn't use Test::More, consider rewriting it so it does. For the
-rest it's best to use a simple C<print "ok $test_num\n"> style to avoid
-broken core functionality from causing the whole test to collapse.
+There are three ways to write a test in the core. Test::More,
+t/test.pl and ad hoc C<print $test ? "ok 42\n" : "not ok 42\n">. The
+decision of which to use depends on what part of the test suite you're
+working on. This is a measure to prevent a high-level failure (such
+as Config.pm breaking) from causing basic functionality tests to fail.
+
+=over 4
+
+=item t/base t/comp
+
+Since we don't know if require works, or even subroutines, use ad hoc
+tests for these two. Step carefully to avoid using the feature being
+tested.
+
+=item t/cmd t/run t/io t/op
+
+Now that basic require() and subroutines are tested, you can use the
+t/test.pl library which emulates the important features of Test::More
+while using a minimum of core features.
+
+You can also conditionally use certain libraries like Config, but be
+sure to skip the test gracefully if it's not there.
+
+=item t/lib ext lib
+
+Now that the core of Perl is tested, Test::More can be used. You can
+also use the full suite of core modules in the tests.
+
+=back
When you say "make test" Perl uses the F<t/TEST> program to run the
test suite. All tests are run from the F<t/> directory, B<not> the