Re: What to test in a new module

[kcott]

G'day Bod,

Obviously, without seeing the module, I can only give generalised information. The following describes how I do testing. It's fairly standard but different authors have their own way of doing things. I also have my own naming conventions: not dissimilar from what many others use (but certainly not universal). I'd suggest looking around CPAN and seeing what others have done.

Firstly, my (skeleton) module directory layout tends to follow this pattern:

Some-Module/
    Changes
    Makefile.PL
    MANIFEST
    MANIFEST.SKIP
    lib/
        Some/
            Module.pm
    README
    t/
        *.t test files here

Test files are typically split into two groups: those generally run for any installation; and, Author Only tests which are normally skipped for a general make test.

General Tests

The first is always "00-load.t". It's short, simple, and just tests that "use Some::Module;" works. It uses Test::More::use_ok() and typically looks something like this:

#!perl -T

use strict;
use warnings;

use Test::More tests => 1;

BEGIN { use_ok('Some::Module') }

diag "Testing Some::Module $Some::Module::VERSION";

If an object-oriented module, the next test is "01-instantiate.t". The complexity of this script will depend on whether there are any instantiation arguments and, if so, whether they are required or optional. Here's a simple example, paraphrased from a real test script:

#!perl -T

use strict;
use warnings;

use Test::More tests => 3;

use Some::Module;

my $sm;
my $eval_ok = 0;

eval {
    $sm = Some::Module::->new();
    1;
} && do {
    $eval_ok = 1;
};

is($eval_ok, 1, 'Test eval OK');
is(defined $sm, 1, 'Test Some::Module object defined');
isa_ok($sm, 'Some::Module');

Individual methods and functions are tested next. Wherever possible, I put tests for each method or function in their own separate scripts. These follow the same naming conventions; for example, "02-some_method.t", "03-some_function.t", and so on. Here you need to test all possible argument combinations and return values. Consider as many problematic use cases as possible and test that they are all handled correctly; add more tests as other problems are encountered (either from your own work or bug reports from others).

I tend to put all tests in their own anonymous block:

#!perl -T

use strict;
use warnings;

use Test::More tests => N;
use Some::Module;

{
    # Isolate tests with one set of arguments
    my $sm = Some::Module::->new(...);
    my @args = (...);
    is($sm->meth(@args), ...
}

{
    # Isolate tests with a different set of arguments
    my $sm = Some::Module::->new(...);
    my @args = (...);
    is($sm->meth(@args), ...
}

There's a plethora of modules in the "Mock:: namespace". Although I haven't used it myself, Test::Mock::LWP looks like it might be useful for you. I didn't spend any time searching for you; this one just happened to stand out; do have a look around for others.

Author Only Tests

These are really only for you. They generally represent sanity checks of the module code, and ancillary files, in your distribution. They are typically triggered by an environment variable having a TRUE value; and are skipped otherwise.

In the spoiler below, I show three scripts that I've pulled verbatim from a random, personal distribution; these are standard for me (with, potentially, some variation in version numbers). I actually use these with all of my $work modules as well (although, they do have a few more as standard).

<Reveal this spoiler or all in this thread>