Test::Warn - Perl extension to test methods for warnings
use Test::Warn; warning_is {foo(-dri => "/")} "Unknown Parameter 'dri'", "dri != dir gives warning"; warnings_are {bar(1,1)} ["Width very small", "Height very small"]; warning_is {add(2,2)} undef, "No warning for calc 2+2"; # or warnings_are {add(2,2)} [], "No warning for calc 2+2"; # what reads better :-) warning_like {foo(-dri => "/")} qr/unknown param/i, "an unknown parameter test"; warnings_like {bar(1,1)} [qr/width.*small/i, qr/height.*small/i]; warning_is {foo()} {carped => "didn't find the right parameters"}; warnings_like {foo()} [qr/undefined/,qr/undefined/,{carped => qr/no result/i}]; warning_like {foo(undef)} 'uninitialized'; warning_like {bar(file => '/etc/passwd')} 'io'; warning_like {eval q/"$x"; $x;/} [qw/void uninitialized/], "some warnings at compile time";
This module provides a few convenience methods for testing warning-based code.
If you are not already familiar with the Test::More manpage, now would be the time to go take a look.
Tests that BLOCK give exactly the one specified warning.
The test fails if the BLOCK warns more then one time or doesn't warn.
If the string is undef,
then the tests succeeds iff the BLOCK doesn't give any warning.
Another way to say that there aren't any warnings in the block
is warnings_are {foo()} [], "no warnings"
.
If you want to test for a warning given by carp
you have to write something like:
warning_is {carp "msg"} {carped => 'msg'}, "Test for a carped warning"
.
The test will fail
if a "normal" warning is found instead of a "carped" one.
Note: warn "foo"
would print something like foo at -e line 1
.
This method ignores everything after the at. That means, to match this warning
you would have to call warning_is {warn "foo"} "foo", "Foo succeeded"
.
If you need to test for a warning at an exactly line,
try something like warning_like {warn "foo"} qr/at XYZ.dat line 5/
.
warning_is and warning_are are only aliases to the same method.
So you also could write
warning_is {foo()} [], "no warning"
or something similar.
I decided to give two methods to have some more readable method names.
A true value is returned if the test succeeds, false otherwise.
The test name is optional, but recommended.
Tests to see that BLOCK gives exactly the specificated warnings. The test fails if the warnings from BLOCK are not exactly the ones in ARRAYREF. If the ARRAYREF is equal to [], then the test succeeds iff the BLOCK doesn't give any warning.
Please read also the notes to warning_is as these methods are only aliases.
If you want more than one test for carped warnings, try this:
warnings_are {carp "c1"; carp "c2"} {carped =
['c1','c2'];> or
warnings_are {foo()} ["Warning 1", {carped =
["Carp 1", "Carp 2"]}, "Warning 2"]>.
Note that {carped =
...}> always has to be a hash ref.
Tests that BLOCK gives exactly one warning and it can be matched by the given regexp. If the string is undef, then the tests succeeds iff the BLOCK doesn't give any warning.
The REGEXP is matched against the whole warning message,
which in general has the form "WARNING at __FILE__ line __LINE__".
So you can check for a warning in the file Foo.pm on line 5 with
warning_like {bar()} qr/at Foo.pm line 5/, "Testname"
.
Perhaps it isn't sensible to perform such a test;
however, you should be aware that matching on a sweeping regular expression
such as 'at', 'file', '\d'
or similar will always pass.
Consider qr/^foo/ if you want to test for warning "foo something" in file foo.pl.
You can also write the regexp in a string as "/.../" instead of using the qr/.../ syntax. Note that the slashes are important in the string, as strings without slashes are reserved for warning categories (to match warning categories as can be seen in the perllexwarn man page).
As with warning_is
,
you can test for warnings via carp
with:
warning_like {bar()} {carped =
qr/bar called too early/i};>
Similar to warning_is
/warnings_are
,
warning_like
and warnings_like
are only aliases to the same methods.
A true value is returned if the test succeeds, false otherwise.
The test name is optional, but recommended.
Tests whether a BLOCK gives exactly one warning of the passed category.
The categories are grouped in a tree,
like it is expressed in perllexwarn.
Note that they have the hierarchical structure from perl 5.8.0,
which is slightly different from how it was organized up through perl 5.6.1.
(You can access the internal hierarchy with
$Test::Warn::Categorization::tree
,
although it isn't recommended).
Thanks to the grouping in a tree, it's possible to test simply for an 'io' warning, instead of testing for a 'closed|exec|layer|newline|pipe|unopened' warning.
Note that compile-time warnings can only be caught in an eval block. So
warning_like {eval q/"$x"; $x;/} [qw/void uninitialized/], "some warnings at compile time";
will work, while it wouldn't work without the eval.
Note also that it isn't yet possible
to test for categories you created yourself with warnings::register
.
Tests to see that BLOCK gives exactly the number of the specificated warnings and all the warnings have to match in the defined order to the passed regexes.
Please read also the notes to warning_like as these methods are only aliases.
Similar to warnings_are
,
you can test for multiple warnings via carp
and for warning categories, too:
warnings_like {foo()} [qr/bar warning/, qr/bar warning/, {carped => qr/bar warning/i}, 'io' ], "I hope you'll never have to write a test for so many warnings :-)";
warning_is
,
warnings_are
,
warning_like
,
warnings_like
by default.
Please note that warnings with newlines inside are making a lot of trouble.
The only sensible way to handle them is to use the warning_like
or
warnings_like
methods.
The background for these problems is that there is no
really secure way to distinguish between warnings with newlines and a trailing
stacktrace.
If a method has its own warn handler,
overwriting $SIG{__WARN__}
,
my test warning methods won't get these warnings.
The warning_like BLOCK CATEGORY, TEST_NAME
method isn't fully tested.
Please pay attention if you use this this calling style,
and report any bugs you find.
Improve this documentation.
The code has some parts doubled - especially in the test scripts. This is really awkward and must be changed.
Please feel free to suggest improvements.
Have a look to the similar Test::Exception module. Test::Trap
Many thanks to Adrian Howard, chromatic and Michael G. Schwern, who have given me a lot of ideas.
Janek Schleicher, <bigj AT kamelfreund.de>
Copyright 2002 by Janek Schleicher
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.