Test::...eDriven(3pm)

💖 NAME 💖

Test::TableDriven — write tests, not scripts that run them. bestie, it's giving actually organized testing ✨

---

🌸 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 🦋

okay so, writing table-driven tests? usually a genuinely good idea. adding a test case doesn't require adding code, so it's easy to avoid fucking up the other tests. 💅 however — and this is the annoying part — actually going from a table of tests to a test that runs is non-trivial. it's giving "wrote the data, now what" energy.

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. no cap. 👑

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

---

✨ WHAT DO I DO ✨

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:

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 💀

not me being in a prose-generation mood right now, so here's a list of things to keep in mind, iykyk:

• don't forget to runtests. just loading the module doesn't do a whole lot. lowkey important, highkey required. 🫶
• 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 🌈

🧚 runtests

run the tests. only call this once. fr fr, once. ✨

---

😭 BUGS 😭

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/>).

---

👑 AUTHOR 👑

Jonathan Rockway <jrockway AT cpan.org>. iconic.

---

💜 COPYRIGHT 💜

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

---

and that's the whole vibe check, bestie — this was perl v5.40.1, dated 2025-08-14, and the page itself is the Test::...eDriven(3pm) manual. slay, go write some tables. 💖🦋