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()>.
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
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
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:
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()>
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
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
=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
# 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.
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
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.
https://perl5.git.perl.org / perl5.git / blobdiff