Test::TableDriven - write tests, not scripts that run them
use A::Module qw/or two!/; use Test::TableDriven ( foo => { input => 'expected output', another => 'test', }, bar => [[some => 'more tests'], [that => 'run in order'], [refs => [qw/also work/]], [[qw/this is also possible/] => { and => 'it works' }], ], ); runtests; sub foo { my $in = shift; my $out = ...; return $out; } sub bar { same as foo }
Writing table-driven tests is usually a good idea. Adding a test case doesn't require adding code, so it's easy to avoid fucking up the other tests. However, actually going from a table of tests to a test that runs is non-trivial.
Test::TableDriven makes writing the test drivers trivial. You simply define your test cases and write a function that turns the input data into output data to compare against. Test::TableDriven will compute how many tests need to be run, and then run the tests.
Test::TableDriven
Concentrate on your data and what you're testing, not plan tests = scalar keys %test_cases> and a big foreach loop.
plan tests =
Start by using the modules that you need for your tests:
use strict; use warnings; use String::Length; # the module you're testing
Then write some code to test the module:
sub strlen { my $in = shift; my $out = String::Length->strlen($in); return $out; }
This strlen function will accept a test case (as $in) and turns it into something to compare against your test cases:
strlen
$in
Oh yeah, you need some test cases:
use Test::TableDriven ( strlen => { foo => 3, bar => 3, ..., }, );
And you'll want those test to run somehow:
runtests;
Now execute the test file. The output will look like:
1..2 ok 1 - strlen: bar => 3 ok 2 - strlen: foo => 3
Add another test case:
strlen => { foo => 3, bar => 3, quux => 4, ..., },
And your test still works:
1..3 ok 1 - strlen: bar => 3 ok 2 - strlen: quux => 4 ok 3 - strlen: foo => 3
Yay.
I'm not in a prose-generation mood right now, so here's a list of things to keep in mind:
Don't forget to runtests. Just loading the module doesn't do a whole lot.
runtests
If a subtest is not a subroutine name in the current package, runtests will die.
If a subtest definition is a hashref, the tests won't be run in order. If it's an arrayref of arrayrefs, then the tests are run in order.
If a test case "expects" a reference, is_deeply is used to compare the expected result and what your test returned. If it's just a string, is is used.
is_deeply
is
Feel free to use Test::More::diag and friends, if you like.
Test::More::diag
Don't print to STDOUT.
Especially don't print TAP to STDOUT :)
Run the tests. Only call this once.
Report them to RT, or patch them against the git repository at:
git clone git://git.jrock.us/Test-TableDriven
(or http://git.jrock.us/).
Jonathan Rockway <jrockway AT cpan.org>.
<jrockway AT cpan.org>
This module is copyright (c) 2007 Jonathan Rockway. You may use, modify, and redistribute it under the same terms as Perl itself.
To install Test::TableDriven, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Test::TableDriven
CPAN shell
perl -MCPAN -e shell install Test::TableDriven
For more information on module installation, please visit the detailed CPAN module installation guide.