Test::SetupTeardown -- Tiny Test::More-compatible module to group tests in clean environments
use Test::SetupTeardown; my $schema; my (undef, $temp_file_name) = tempfile(); sub begin { say "We're about to start testing!"; } sub setup { $schema = My::DBIC::Schema->connect("dbi:SQLite:$temp_file_name"); $schema->deploy; } sub teardown { unlink $temp_file_name; } sub end { say "We're done testing now."; } my $environment = Test::SetupTeardown->new(begin => \&begin, setup => \&setup, teardown => \&teardown, end => \&end); $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(...);
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 state before running their tests, and is left in a known state after.
setup
teardown
A similar feature is provided in Test::Class, but this is instance-based instead of class-based. You can easily make this closer to classes with a little work though.
my $environment = Test::SetupTeardown->new(setup => CODEREF, teardown => CODEREF);
The constructor for Test::SetupTeardown.
All of the begin, setup, teardown, end arguments are optional (although if you leave them all out, all you've accomplished is adding a header to your tests).
begin
end
The begin callback runs immediately before new returns.
new
The end callback is run by the environment object's DESTROY method. A signal handler tries to ensure that if the tests are interrupted by a signal, the DESTROY method still runs (it normally wouldn't).
DESTROY
Support for begin and end was added in version 0.004. Versions before this will simply ignore unknown callbacks.
$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).
run_test
done_testing;
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.
note()
A specific test run can be selected through the environment variable TEST_ST_ONLY, e.g.:
TEST_ST_ONLY
TEST_ST_ONLY='reticulating splines' prove -lrvm t/
This will cause all test cases not called "reticulating splines" to be completely skipped. They will not count against the test plan, so if you're using this feature, be sure to use no plan and call done_testing instead.
done_testing
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.
Test::More
Fabrice Gabolde <fga@cpan.org>
Copyright (C) 2012, 2013, 2017 SFR
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.
To install Test::SetupTeardown, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Test::SetupTeardown
CPAN shell
perl -MCPAN -e shell install Test::SetupTeardown
For more information on module installation, please visit the detailed CPAN module installation guide.