On Wed, Jan 02, 2002 at 05:10:14PM +0000, Mark Fowler wrote:
> Is there any commonly accepted knowledge about how one should write tests
> for "Test" modules that one might construct using Test::Builder? In
> particular, how does one test that one of your new test fails when it
> should?
>
> I did have an idea about how nice it would be if you could call a method
> in Test::Builder that would cause the next call to ok() to fail if it
> should pass and vice versa (and return true where it would have returned
> true and false when it would have returned true.)
Since everything winds up using ok() (though that's not officially
documented, I'll do that) you can simply override Test::Builder::ok().
sub My::Builder::ok {
my($self, $test, $name) = @_;
$self->SUPER::ok(!$test, $name);
}
but that only checks that the basic test logic is ok. None
of your diagnostic output is checked.
In order to check diagnostic output...
Redirect the error output to a simple tied filehandle (PRINT is
about all you need) using Test::Builder->failure_output and
todo_output.
Examine the output stored in the tied filehandle to see if its
what you expected.
Test::Simple/More/Builder's t/fail*.t tests do this in varying levels
of contortions. They're a bit brutish since they largely predate
Test::Builder and can't trust it anyway, having to do odd things like
writing its own ok() function.
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Do you actually think about what you are saying or is it an improvisational
game of Mad Libs that you play in your head?
