Test::Tester allows you to temporarily divert test results to another
test result collector (which you can then throw away). It diverts the
results at the method call level so it's like the diverted tests never
ran (it does NOT capture STDOUT, Test::Tester sticks to the documented
interface, rather than hoping the Test::Builder never changes it's
output).
There's no obligation on you to actually use the captured test
results. The interface isn't set up for doing what you're talking
about but the following demonstrates how to do it and it could be
hidden away behind a function. In the code below, the test subroutine
is called 3 times but only 2 of them produce test resuls, the middle
call produces no output and has no effect on the test numbering etc.
use strict;
use warnings;
use Test::Tester qw(no_plan run_tests);
use Test::More;
my $delegator = Test::Tester->new_new();
my $capture = Test::Tester->capture();
my $i = 1;
sub some_tests
{
my $really_test = shift;
local $delegator->{Object} = $really_test ? $delegator->{Object} : $capture;
# depending on $really_test these tests may or may not be logged
pass("pass $i");
$i++;
}
some_tests(1);
some_tests(0);
some_tests(1);
F
On 20/02/07, Ovid <[EMAIL PROTECTED]> wrote:
Here's a common enough problem that I assume someone else has solved
it.
Tools in question:
Test::Class
Test::WWW::Mechanize
We want to test creating users (pseudo-code, but close to what we
actually use):
sub add_user : Tests(5) {
my $test = shift;
my $mech = $test->mech;
$mech->get_ok( $add_user_page, 'get the "Add User" page' );
$mech->submit_form(
form_name => 'add_user',
fields => { name => $some_name }
);
$mech->content_like( qr/User added/ );
$mech->back;
$mech->submit_form(
form_name => 'add_user',
fields => { name => $some_other_name }
);
$mech->content_like( qr/User added/ );
$mech->get_ok( $user_page, 'get the "List User" page' );
$mech->content_like( qr/2 users found/ );
}
So that's all well and good, but another class has another method where
we to add accounts, but we must have a customer backing each account
successfully added. We'd rather not simply duplicate the above logic
and since the code's already written, I had the (quite possibly stupid)
idea of rewriting the above like this:
sub add_user : Tests(5) {
my $test = shift;
my $mech = $test->mech;
my $override = override_if_fixture(
test => $test,
mech => $mech,
overrides => {
get_ok => sub {
my ( $mech, $page ) = @_;
$mech->get($page);
},
content_like => sub {},
}
);
$mech->get_ok( $add_user_page, 'get the "Add User" page' );
$mech->submit_form(
form_name => 'add_user',
fields => { name => $some_name }
);
$mech->content_like( qr/User added/ );
$mech->back;
$mech->submit_form(
form_name => 'add_user',
fields => { name => $some_other_name }
);
$mech->content_like( qr/User added/ );
$mech->get_ok( $user_page, 'get the "List User" page' );
$mech->content_like( qr/2 users found/ );
}
The idea is, in this scope, we'd convert the 'get_ok' and
'content_like' methods to *not* be tests for the current scope. This
allows us to use our tests as test fixtures rather than duplicate this
logic.
I think this is a horribly clumsy idea, but the above is a simplified
example and some test data could get hairy to setup and if we change
our Web pages, I'd hate to find all of the duplicated logic for setting
up this test data and testing that it actually works (note that we
could be testing a remote server and not always be in a position to
access the database directly).
Thoughts?
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
