NAME

SYNOPSIS

   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 }

DESCRIPTION

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

WHAT DO I DO

   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:

   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.

DETAILS

• 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 :)

EXPORT

BUGS

   git clone git://git.jrock.us/Test-TableDriven

(or <http://git.jrock.us/>).

AUTHOR

COPYRIGHT