NAME

Test::SetupTeardown -- Tiny Test::More-compatible module to group tests in clean environments

SYNOPSIS

use Test::SetupTeardown;

my $schema;
my (undef, $temp_file_name) = tempfile();

sub setup {
    $schema = My::DBIC::Schema->connect("dbi:SQLite:$temp_file_name");
    $schema->deploy;
}

sub teardown {
    unlink $temp_file_name;
}

my $environment = Test::SetupTeardown->new(setup => \&setup,
                                           teardown => \&teardown);

$environment->run_test('reticulating splines', sub {
    my $spline = My::Spline->new(prereticulated => 0);
    can_ok($spline, 'reticulate');
    $spline->reticulate;
    ok($spline->is_reticulated, q{... and reticulation state is toggled});
                       });

$environment->run_test(...);

DESCRIPTION

This module provides very simple support for xUnit-style setup and teardown methods. It is intended for developers who want to ensure their testing environment is in a known-good state before running their tests, and is left in an known-rather-okay state after.

A similar feature is provided in Test::Class, but not everyone wants to use that.

METHODS

new

my $environment = Test::SetupTeardown->new(setup => CODEREF,
                                           teardown => CODEREF);

The constructor for Test::SetupTeardown.

Both the setup and teardown arguments are optional (although if you leave them both out, all you've accomplished is adding a header to your tests).

run_test

$environment->run_test('reticulating splines',
                       sub { ok(...); ... });

This method runs the setup callback, then the tests, then the teardown callback. If an exception is thrown in the coderef, it is caught by run_test, then the teardown runs, then the exception is thrown again (otherwise you'd get all green on your test report since the flow would proceed to the done_testing; at the end of your test file).

No arguments are passed to either the setup, teardown or test callbacks. Perl supports closures so this has not been a problem so far (although it might become one).

The description is displayed before the test results with Test::Builder's note() method.

BUGS AND LIMITATIONS

Currently there is no simple way, short of editing your tests, to leave traces of your environment when tests have failed so you can go all forensic on your SQLite database and determine what went wrong.

I'm considering two options:

• Provide the option to not run the teardown callback when tests have failed or an exception has been thrown. Trying to determine if tests have failed is probably going to be rather hard since at no point Test::SetupTeardown is aware of what tests actually are.

• Provide named callbacks instead of a single teardown (and, why not, setup, except I don't really see what you'd use them for). Then during the test the user can decide which ones to disable depending on what he wants to autopsy.

SEE ALSO

Test::More

AUTHOR

Fabrice Gabolde <fabrice.gabolde@uperto.com>

COPYRIGHT AND LICENSE

Copyright (C) 2012 SFR

License TBD.