|
NAMETest::Debugger - Create Test Scripts which Generate Log FilesSYNOPSISuse Test::Debugger; plan(tests => 1, log_file => 'test.log'); ok($actual, $expected, $message, $error); # OR Object-Oriented use Test::Debugger; my $t = Test::Debugger->new( tests => 1, log_file => 'test.log', ); # set the order of the parameters passed to 'ok' $t->param_order('ok' => [qw(self expected actual message error)]); $t->ok($expected, $actual, $description, $error_message); $t->todo($expected, $actual, $description, $error_message); $t->skip($because, $expected, $actual, $description, $error); $t->ok_ne($expected, $actual, $description, $error_message); $t->ok_gt($expected, $actual, $description, $error_message); $t->ok_ge($expected, $actual, $description, $error_message); $t->ok_lt($expected, $actual, $description, $error_message); $t->ok_le($expected, $actual, $description, $error_message); $t->ok_re($expected, $actual, $description, $error_message); DESCRIPTIONHave you ever tried to debug a test script that is failing tests? Without too many modifications, your test script can generate a log file with information about each failed test.You can take your existing test script, and with (hopefully) very little effort, convert it to use Test::Debugger. Then re-run your modified test and view the log file it creates. Object-Oriented InterfaceTest::Debugger can be run using exported subroutines, or using an object-oriented interface.The object-oriented interface allows for easier access to some types of functionality, such as comparision operators other than 'eq'. You start by creating a test object. my $t = Test::Debugger->new(%params); The "new" method calls "plan" automatically, so you can pass your "plan" parameters directly to "new". The three most basic methods are "ok", "todo" and "skip". You can rearrange the order of the parameters to these methods by running "param_order". You must run "param_order" for the testing subroutines to work as methods. $t->param_order('ok' => ['self', 'actual', 'expected']); The key here is the word self. The default param order does not include self as a valid parameter. The example above sets the valid parameters to pass to "ok", including the test object, the value we are testing, and the value we expect it to match against. A parameter order need only be assigned for "ok". The "todo" and "skip" methods will mimic the order assigned for "ok", if they are undefined. Now we can set up our tests: $t->ok($actual, $expected); An explanation of each method can be found further down in this document. Subroutine InterfaceThe interface for Test::Debugger is based loosely on the interface for Test.pm. You have four subroutines exported into your namespace: "plan", "ok", "skip", and "todo".You should "plan", but it is not as strictly enforced as in Test.pm. The default order of arguments to "ok" and "todo" is: ok($actual, $expected, $message, $error, $operator); You must supply at least an $actual value, and you should supply the first three parameters. You can change the order of the parameters with "param_order". Log FileI generally name my test log file 'test.log', and add an entry to my Makefile.PL to remove it on 'make clean'.WriteMakefile( ... 'clean' => { 'FILES' => 'test.log', }, ); If a test fails, is skipped, or is marked todo (and fails), an entry is made to the log file. Each entry looks similar to this: t/todo.t 1 TODO. should fail as TODO ### Expected ### 1 ### Actual Results ### 0 The first part is the name of the test file. The number is the subtest within the test file. The word "TODO" means that this test was not expected to succeed, because code it relies on is not finished. This word could also have been "FAILED" or "SKIPPED". On the second line, we see the $message provided to the test. We would see the $error on the third line, if that had been provided. Then the expected value and the actual value are displayed. An extra newline is appended to the actual value, in the log file, so that there is a blank line between entries. Extra DebuggingIf the test log file is not sufficient to debug your code, or your test, you may enable the "note" subroutine of Devel::Messenger and write to another file, perhaps called something like 'debug.txt'.use Devel::Messenger qw(note); local *Test::Debugger::note = note { output => 'debug.txt' }; Test::Debugger will "note" the test it is working on. You can then place notes in your module, and they will be grouped by test number. Methods/SubroutinesMost methods may be called as a subroutine, rather than as a method.
AUTHORNathan Gray - kolibrie@southernvirginia.eduCOPYRIGHTTest::Debugger is Copyright (c) 2003 Nathan Gray. All rights reserved.You may distribute under the terms of either the GNU General Public License, or the Perl Artistic License. SEE ALSOperl(1), Test::Harness(3), Devel::Messenger(3).
Visit the GSP FreeBSD Man Page Interface. |