An overview of the testing modules available on CPAN
CPAN is filled with great modules to help you test your code. Here's a short list of what's available, so you don't reinvent the wheel.
If you have a module to add to the list,
please email andy@petdance.com.
General testing modules
Test::AtRuntime
Assertion-like testing while your program runs.
Test::Benchmark
Compares two functions to ensure one is faster than another:
use Test::Benchmark;
is_faster(-10, sub {...}, sub {...}, "this is faster than that")
Test::Class
xUnit style testing that works well with Test::Builder based modules (the majority of other testing modules). This means it can integrate into an existing setup relatively easily.
Test::Cmd
Testing of scripts/programs by their external interface rather than innards.
Test::Data
Comprises 4 submodules that provide a number of functions to test the contents of arrays, hashes, scalars and functions. These make it easy to test various boundaries and edge cases without writing much code.
Test::Debugger
Emits a trace of the test script to file, for perusal in the event of failures.
Test::Deep
Extremely flexible and powerful deep comparisons of data structures. Ideal for testing that a given structure not only is equal to an ideal model, but also for determining whether they are similar. Also good for checking lightly nested structures (e.g. that a response from an address book query has well formed records).
Test::Differences
Tests long strings and data structures, giving a readable output (unlike testing long strings with Test::More's is function).
Test::Extreme
Another xUnit-ish testing framework. Very easy to use. Able to output both xUnit style and traditional Perl style.
Test::FIT
Provides a CGI interface to writing and running test suites.
Test::File
Tests file attributes (empty, of particular sizes, readable, executable, writeable, etc.).
Test::Inline
Allows you to embed your tests in your POD in your program file, thus allowing you to test while you document, or test while you code, or both. One sideeffect is that your sample code can be test code.
Test::LectroTest
LectroTest is an automatic, specification-based testing tool for Perl. The project was inspired by Koen Claessen and John Hughes's QuickCheck for the Haskell programming language.
Testing a hypothetical square function:
Property {
##[ x <- Int #]##
square( $x ) == $x * $x;
}, name => "Finding $x's square";
Test::LongString
Testing of long strings, allowing one to see precisely where the inequality, or non-match, is with ease.
Test::ManyParams
Combinatorial subroutine argument testing. Lets you test every combination of arguments to a function.
Test::MockModule
Easily override subroutines in a module for unit testing.
Test::MockObject
Lets you create objects that respond to methods in particular ways, thus letting you test how your own code handles objects with such return values.
Test::More
The most common testing module to use. Appropriate feature set for the majority of test cases and now standard in Perl (from 5.6.2 and 5.8.0).
Test::Reporter
Module to let you send make test results to the CPAN testers. Includes the handy cpantest program to make command-line reporting easy.
Test::Simple
The basic testing module, which you'll rarely want to use on its own, since Test::More completely supercedes it.
Test::SimpleUnit
Unit test wrapper functions around the standard testing functions. Allows you to specify setup functions, plus teardown functions to get run in the case of failure.
Test::Smoke
Framework for testing distributions of Perl itself. Not normally used by the general public.
Test::Unit
JUnit testing for Perl.
Test::Verbose
Runs verbose tests on a test file. Seems to be obviated by the prove program now included with Test::Harness.
Database testing modules
DBD::Mock
DBD::Mock is a DBI-compliant database driver that allows you to prepare and execute SQL statements, seed resultsets, and inspect the results of all calls.
An example from the SYNOPSIS:
use DBI;
# ...connect as normal, using 'Mock' as your driver name
my $dbh = DBI->connect( 'DBI:Mock:', '', '' )
|| die "Cannot create handle: $DBI::errstr\n";
# ...create a statement handle as normal and execute with parameters
my $sth = $dbh->prepare( 'SELECT this, that FROM foo WHERE id = ?' );
$sth->execute( 15 );
# Now query the statement handle as to what has been done with it
my $params = $sth->{mock_params};
print "Used statement: ", $sth->{mock_statement}, "\n",
"Bound parameters: ", join( ', ', @{ $params } ), "\n";
Test::DatabaseRow
Given a DBI database handle, can test to see if the database contains tables with particular rows. Useful for testing that database modifications went well.
# SQL-based test
row_ok( sql => "SELECT * FROM contacts WHERE cid = '123'",
tests => [ name => "trelane" ],
label => "contact 123's name is trelane");
# test with shortcuts
row_ok( table => "contacts",
where => [ cid => 123 ],
tests => [ name => "trelane" ],
label => "contact 123's name is trelane");
Data-specific testing modules
Test::Env
Tests that one's environment has appropriate data.
Test::Files
Tests files and directories have particular contents.
Test::ISBN
Verify ISBNs and parts of ISBNs against Business::ISBN.
Test::Mail
Testing that email is sent and received properly.
Test::XML
Helper functions for testing XML for syntactic equivalency, even if the strings themselves are different.
Web testing modules
Apache::Test
Allows you to run tests for Apache-based software. Also lets you run tests inside Apache. Not limited to mod_perl.
- Introductory tutorial slides
http://www.modperlcookbook.org/~geoff/slides/ApacheCon/2003/apache-test-printable.ppt.gz
- perl.com article on Apache::Test
- Docs from apache.org
Test::HTML::Content
Tests HTML has (or hasn't) particular links, text, tags, comments and such. Very useful for testing websites (see also WWW::Mechanize and Test:HTML::Lint).
Test::HTML::Lint
Checks that HTML is well formed as per HTML::Lint.
Test::HTML::Tidy
Checks that HTML is well formed as per HTML::Tidy.
Test::HTTPStatus
Ensures HTTP responses have appropriate values.
Test::WWW::Mechanize
Subclass of WWW::Mechanize with convenience methods for automated testing.
Module-testing modules
Test::Builder::Tester
Runs tests on other Test:: modules based on Test::Builder.
Test::Distribution
Performs basic Kwalitee checking on modules: checks that they have well formed POD, they compile, they all define the same $VERSION, they have their prerequisites in the Makefile.PL and that some standard files exist.
Test::Exception
Testing that bits of code die or don't die appropriately, and with the right errors.
Test::Manifest
Executes your tests in a particular non-alphabetic order without having to name them with numeric prefixes.
Test::NoWarnings
Test for making sure that your test didn't emit any warnings.
Test::Pod
Checks a given POD or Perl file for syntactic validity. Also has a function to let you easily check all files in your distribution at once.
Test::Pod::Coverage
Checks a given POD or Perl file for syntactic validity. Also has a function to let you easily check all files in your distribution at once.
Test::Portability::Files
Checks the portability the names of the files in a distribution. The tests use the advice listed in perlport, section "Files and Filesystems".
Test::Prereq
Checks that your Makefile.PL has the proper prerequisites specified.
Test::Signature
Verifies that the signature of a module, as created by Module::Signature, is correct.
Test::Tester
Runs tests on other Test:: modules based on Test::Builder.
Test::Version
Checks module files for proper version information.
Test::Warn
Handy module for testing code that might throw a warning. The testing function captures any warnings, so you can check them against a regex.
For example, this code checks that WWW::Mechanize's warn() method does indeed throw a warning.
my $m = WWW::Mechanize->new;
isa_ok( $m, 'WWW::Mechanize' );
warning_like {
$m->warn( "Something bad" );
} qr/Something bad.+line \d+/,
"Passes the message, and includes the line number";
Test::Without::Module
Allows you to deliberately hide modules from a program even though they are installed. This is mostly useful for testing modules that have a fallback when a certain dependency module is not installed.
CONTRIBUTORS
The following people have helped contribute to this page: Andy Lester, Dominic Mitchell Philipe 'BooK' Bruhat, Chris Winters, Per Christian Nødtved, and the late, great Iain Truskett.

