GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages


Manual Reference Pages  -  TEST::TABLEDRIVEN (3)

.ds Aq ’

NAME

Test::TableDriven - write tests, not scripts that run them

CONTENTS

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

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.

WHAT DO I DO

Start by using the modules that you need for your tests:



   use strict;
   use warnings;
   use String::Length; # the module youre 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

I’m not in a prose-generation mood right now, so here’s a list of things to keep in mind:
o Don’t forget to runtests. Just loading the module doesn’t do a whole lot.
o If a subtest is not a subroutine name in the current package, runtests will die.
o 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.
o 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.
o Feel free to use Test::More::diag and friends, if you like.
o Don’t print to STDOUT.
o Especially don’t print TAP to STDOUT :)

EXPORT

    runtests

Run the tests. Only call this 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>.

COPYRIGHT

This module is copyright (c) 2007 Jonathan Rockway. You may use, modify, and redistribute it under the same terms as Perl itself.
Search for    or go to Top of page |  Section 3 |  Main Index


perl v5.20.3 TEST::TABLEDRIVEN (3) 2007-09-16

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.