Provided by: libtest-tabledriven-perl_0.02-1_all bug


       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' }],


          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.

       Concentrate on your data and what you're testing, not "plan tests =" scalar keys
       %test_cases> and a big foreach loop.


       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:

       Oh yeah, you need some test cases:

          use Test::TableDriven (
              strlen => { foo => 3,
                          bar => 3,

       And you'll want those test to run somehow:


       Now execute the test file.  The output will look like:

          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:

          ok 1 - strlen: bar => 3
          ok 2 - strlen: quux => 4
          ok 3 - strlen: foo => 3



       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.

       ·   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.

       ·   Feel free to use "Test::More::diag" and friends, if you like.

       ·   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://

       (or <>).


       Jonathan Rockway "<jrockway AT>".


       This module is copyright (c) 2007 Jonathan Rockway.  You may use, modify, and redistribute
       it under the same terms as Perl itself.