Programming Perl, 4th Edition

Testing Your Modules

Perl’s testing culture is one of its most compelling features. We’ve already told you about CPAN Testers, the people who test all CPAN distributions on a variety of platforms. As an author, it’s up to you to create your own tests. We’re not going to tell you everything involved with that, because it’s already extensively covered in other titles such as Intermediate Perl and Perl Testing: A Developer’s Notebook.

Internal testing

If you are using either of the two standard distribution build tools, you already have a test harness in place. You run the test target:

% make test

% ./Build test

Those both do the same thing: they look for either a test.pl file or a t/ directory. Using a test.pl file is the old way, in which just one file holds all tests. Using a t/ subdirectory is a better approach because it can hold multiple test files, each one ending with .t, and the test harness runs all of the subtests.

Each test file is just a Perl program, most likely using Test::More to do the work. Here’s an example test file that loads your Math::MySum module and tests its my_sum method:

use strict;
use warnings;
use Test::More;

BEGIN { use_ok( "Math::MySum" ) }
can_ok( "Math::MySum", "my_sum" );

my($i, $j) = (1, 3);
my $string = "Amelia";

is($i + $j, Math::MySum–>my_sum( $i, $j ),
    "Sum of $i and $j is 4");

like($string, qr/mel/, "String has mel in it");

done_testing;

These programs output TAP (Test Anywhere Protocol), a simple format that Larry invented and others extended.^[