ExtUtils::TBone - a "skeleton" for writing "t/*.t" test files.
Include a copy of this module in your t directory (as t/ExtUtils/TBone.pm),
and then write your t/*.t files like this:
use lib "./t"; # to pick up a ExtUtils::TBone
use ExtUtils::TBone;
# Make a tester... here are 3 different alternatives:
my $T = typical ExtUtils::TBone; # standard log
my $T = new ExtUtils::TBone; # no log
my $T = new ExtUtils::TBone "testout/Foo.tlog"; # explicit log
# Begin testing, and expect 3 tests in all:
$T->begin(3); # expect 3 tests
$T->msg("Something for the log file"); # message for the log
# Run some tests:
$T->ok($this); # test 1: no real info logged
$T->ok($that, # test 2: logs a comment
"Is that ok, or isn't it?");
$T->ok(($this eq $that), # test 3: logs comment + vars
"Do they match?",
This => $this,
That => $that);
# That last one could have also been written...
$T->ok_eq($this, $that); # does 'eq' and logs operands
$T->ok_eqnum($this, $that); # does '==' and logs operands
# End testing:
$T->end;
This module is intended for folks who release CPAN modules with "t/*.t" tests. It makes it easy for you to output syntactically correct test-output while at the same time logging all test activity to a log file. Hopefully, bug reports which include the contents of this file will be easier for you to investigate.
Pretty much as described by Test::Harness
, with a special
"# END" comment placed at the very end:
1..3
ok 1
not ok 2
ok 3
# END
A typical log file output by this module looks like this:
1..3
** A message logged with msg().
** Another one.
1: My first test, using test(): how'd I do?
1: ok 1
** Yet another message.
2: My second test, using test_eq()...
2: A: The first string
2: B: The second string
2: not ok 2
3: My third test.
3: ok 3
# END
Each test() is logged with the test name and results, and the test-number prefixes each line. This allows you to scan a large file easily with "grep" (or, ahem, "perl"). A blank line follows each test's record, for clarity.
ok 12 not ok 13
Use it like this:
$T->ok(-e $dotforward);
Or better yet, like this:
$T->ok((-e $dotforward),
"Does the user have a .forward file?");
Or even better, like this:
$T->ok((-e $dotforward),
"Does the user have a .forward file?",
User => $ENV{USER},
Path => $dotforward,
Fwd => $ENV{FWD});
That last one, if it were test #3, would be logged as:
3: Does the user have a .forward file?
3: User: "alice"
3: Path: "/home/alice/.forward"
3: Fwd: undef
3: ok
You get the idea. Note that defined quantities are logged with delimiters
and with all nongraphical characters suitably escaped, so you can see
evidence of unexpected whitespace and other badnasties.
Had "Fwd" been the string "this\nand\nthat", you'd have seen:
3: Fwd: "this\nand\nthat"
And unblessed array refs like ["this", "and", "that"] are
treated as multiple values:
3: Fwd: "this"
3: Fwd: "and"
3: Fwd: "that"
ASTRING eq BSTRING
, and
logs the operands as 'A' and 'B'.
ANUM == BNUM
, and
logs the operands as 'A' and 'B'.
new(PATH)
and typical()
.
typical
constructor.
File::Spec
; this method
dates back to a more-innocent time when File::Spec was younger
and less ubiquitous.
Paths are assumed to be absolute. To signify a relative path, the first DIR must be ".", which is processed specially.
On Mac, the path does end in a ':'. On Unix, the path does not end in a '/'.
$Id: TBone.pm,v 1.124 2001/08/20 20:30:07 eryq Exp $
"END"
to "# END"
; apparently, "END" is
not a directive. Maybe it never was.
Thanks to Michael G. Schwern for the bug report.
The storyteller need not say "the end" aloud; Silence is enough.
Automatically invoke log_warnings()
when constructing
via typical()
.
Created: Friday-the-13th of February, 1998.
Eryq (
Go to
Enjoy. Yell if it breaks.