NAME

Test::Aggregate - Aggregate *.t tests to make them run faster.

VERSION

Version 0.04

SYNOPSIS

use Test::Aggregate;

my $tests = Test::Aggregate->new( {
    dirs => $aggregate_test_dir,
} );
$tests->run;

DESCRIPTION

WARNING: this is ALPHA code. The interface is not guaranteed to be stable.

A common problem with many test suites is that they can take a long time to run. The longer they run, the less likely you are to run the tests. This module borrows a trick from Apache::Registry to load up your tests at once, create a separate package for each test and wraps each package in a method named run_the_tests. This allows us to load perl only once and related modules only once. If you have modules which are expensive to load, this can dramatically speed up a test suite.

USAGE

Create a separate directory for your tests. This should not be a subdirectory of your regular test directory. Write a small driver program and put it in your regular test directory (t/ is the standard):

use Test::Aggregate;
my $other_test_dir = 'aggregate_tests';
my $tests = Test::Aggregate->new( {
   dirs => $other_test_dir
});
$tests->run;

Take your simplest tests and move them, one by one, into the new test directory and keep running the Test::Aggregate program. You'll find some tests will not run in a shared environment like this. You can either fix the tests or simply leave them in your regular test directory. See how this distribution's tests are organized for an example.

METHODS

new

my $tests = Test::Aggregate->new(
    {
        dirs          => 'aggtests',
        dump          => 'dump.t',     # optional
        shuffle       => 1,            # optional
        matching      => qr/customer/, # optional
        set_filenames => 1,            # optional
    }
);

Creates a new Test::Aggregate instance. Accepts a hashref with the following keys:

  • dirs (mandatory)

    The directories to look in for the aggregated tests. This may be a scalar value of a single directory or an array refernce of multiple directories.

  • dump (optional)

    You may list the name of a file to dump the aggregated tests to. This is useful if you have test failures and need to debug why the tests failed.

  • shuffle (optional)

    Ordinarily, the tests are sorted by name and run in that order. This allows you to run them in any order.

  • matching (optional)

    If supplied with a regular expression (requires the qr operator), will only run tests whose filename matches the regular expression.

  • set_filenames (optional)

    If supplied with a true value, this will cause the following to be added for each test:

    local $0 = $test_filename;

    Tests which depend on the value of $0 can often be made to work with this.

run

$tests->run;

Attempts to aggregate and run all tests listed in the directories specified in the constructor.

CAVEATS

Not all tests can be included with this technique. If you have Test::Class tests, there is no need to run them with this. Otherwise:

  • __END__ and __DATA__ tokens.

    These won't work and the tests will call BAIL_OUT() if these tokens are seen.

  • BEGIN and END blocks.

    Since all of the tests are aggregated together, BEGIN and END blocks will be for the scope of the entire set of aggregated tests.

  • Syntax errors

    Any syntax errors encountered will cause this program to BAIL_OUT(). This is why it's recommended that you move your tests into your new directory one at a time: it makes it easier to figure out which one has caused the problem.

  • no_plan

    Unfortunately, due to how this works, the plan is always no_plan. If Test::Builder implements "deferred plans", we can get a bit more safety. See http://groups.google.com/group/perl.qa/browse_thread/thread/d58c49db734844f4/cd18996391acc601?#cd18996391acc601 for more information.

  • No 'skip_all' tests, please

    Tests which potentially 'skip_all' will cause the aggregate test suite to abort prematurely. Do not attempt to aggregate them. This may be fixed in a future release.

  • Variable "$x" will not stay shared at (eval ...

    Because each test is wrapped in a method call, any of your subs which access a variable in an outer scope will likely throw the above warning. Pass in arguments explicitly to suppress this.

    Instead of:

    my $x = 17;
    sub foo {
        my $y = shift;
        return $y + $x;
    }

    Write this:

    my $x = 17;
    sub foo {
        my ( $y, $x ) = @_;
        return $y + $x;
    }
  • Singletons

    Be very careful of code which loads singletons. Oftimes those singletons in test suites may be altered for testing purposes, but later attempts to use those singletons can fail dramatically as they're not expecting the alterations. (Your author has painfully learned this lesson with database connections).

DEBUGGING AGGREGATE TESTS

Before aggregating tests, make sure that you add tests one at a time to the aggregated test directory. Attempting to add many tests to the directory at once and then experiencing a failure means it will be much harder to track down which tests caused the failure.

Debugging aggregated tests which fail is a multi-step process. Let's say the following fails:

my $tests = Test::Aggregate->new(
    {
        dump    => 'dump.t',
        shuffle => 1,
        dirs    => 'aggtests',
    }
);
$tests->run;

Manually run the tests

The first step is to manually run all of the tests in the aggtests dir.

prove -r aggtests/

If the failures appear the same, fix them just like you would fix any other test failure and then rerun the Test::Aggregate code.

Sometimes this means that a different number of tests run from what the aggregted tests run. Look for code which ends the program prematurely, such as an exception or an exit statement.

Run a dump file

If this does not fix your problem, create a dump file by passing dump => $dumpfile to the constructor (as in the above example). Then try running this dumpfile directly to attempt to replicate the error:

prove -r $dumpfile

Tweaking the dump file

Assuming the error has been replicated, open up the dump file. The beginning of the dump file will have some code which overrides some Test::Builder internals. After that, you'll see the code which runs the tests. It will look similar to this:

if ( __FILE__ eq 'dump.t' ) {
    Test::More::ok(1, "******** running tests for aggtests/boilerplate.t ********");
    aggtestsboilerplatet->run_the_tests;
    Test::More::ok(1, "******** running tests for aggtests/subs.t ********");
    aggtestssubst->run_the_tests;
    Test::More::ok(1, "******** running tests for aggtests/00-load.t ********");
    aggtests00loadt->run_the_tests;
    Test::More::ok(1, "******** running tests for aggtests/slow_load.t ********");
    aggtestsslow_loadt->run_the_tests;
}

You can try to narrow down the problem by commenting out all of the run_the_tests lines and gradually reintroducing them until you can figure out which one is actually causing the failure.

COMMON PITFALLS

BEGIN, CHECK, INIT and END blocks

Remember that since the tests are now being run at once, these blocks will no longer run on a per-test basis, but will run for the entire aggregated set of tests. You may need to examine these individually to determine the problem.

Test::NoWarnings

This is a great test module. When aggregating tests together, however, it can cause pain as you'll often discover warnings that you never new existed. For a quick fix, add this before you attempt to run your tests:

$INC{'Test/NoWarnings.pm'} = 1;

That will disable Test::NoWarnings, but you'll want to go in later to fix them.

Paths

Many tests make assumptions about the paths to files and moving them into a new test directory can break this.

$0

Tests which use $0 can be problematic as the code is run in an eval through Test::Aggregate and $0 may not match expectations. This also means that it can behave differently if run directly from a dump file.

As it turns out, you can assign to $0! If set_filenames => 1 is passed to the constructor, every test will have the following added to its package:

local $0 = $test_file_name;

Minimal test case

If you cannot solve the problem, feel free to try and create a minimal test case and send it to me (assuming it's something I can run).

AUTHOR

Curtis Poe, <ovid at cpan.org>

BUGS

Please report any bugs or feature requests to bug-test-aggregate at rt.cpan.org, or through the web interface at http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Test-Aggregate. I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.

SUPPORT

You can find documentation for this module with the perldoc command.

perldoc Test::Aggregate

You can also look for information at:

ACKNOWLEDGEMENTS

Many thanks to mauzo (http://use.perl.org/~mauzo/ for helping me find the 'skip_all' bug.

Thanks to Johan Lindström for pointing me to Apache::Registry.

COPYRIGHT & LICENSE

Copyright 2007 Curtis "Ovid" Poe, all rights reserved.

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

1 POD Error

The following errors were encountered while parsing the POD:

Around line 552:

Non-ASCII character seen before =encoding in 'Lindström'. Assuming UTF-8