Package: libtest-warn-perl
Version: 0.08-2
Severity: minor
Tags: patch
The messages printed by this package are not fully idiomatic English.
Please find attached a patch for the current stable version.
(The latest upstream version on CPAN is still 0.08, from 2003.)
/* era */
--
If this were a real .signature, it would suck less. Well, maybe not.
--- Warn.pm.orig 2005-08-10 13:18:54.057617480 +0300
+++ Warn.pm 2005-08-10 13:41:46.980901416 +0300
@@ -9,13 +9,13 @@
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 to calc 2+2"; # or
- warnings_are {add(2,2)} [], "No warning to calc 2+2"; # what reads better :-)
+ warning_is {add(2,2)} undef, "No warning for calc 2+2"; # or
+ warnings_are {add(2,2)} [], "No warning for calc 2+2"; # 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 found the right parameters'};
+ 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';
@@ -27,9 +27,9 @@
=head1 DESCRIPTION
-This module provides a few convenience methods for testing warning based code.
+This module provides a few convenience methods for testing warning-based code.
-If you are not already familiar with the Test::More manpage
+If you are not already familiar with the Test::More manpage,
now would be the time to go take a look.
=head2 FUNCTIONS
@@ -38,29 +38,29 @@
=item warning_is BLOCK STRING, TEST_NAME
-Tests that BLOCK gives exactly the one specificated warning.
-The test fails if the BLOCK warns more then one times or doesn't warn.
+Tests that BLOCK gives exactly the one specified warning.
+The test fails if the BLOCK warns more than once, 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 ary warnings in the block,
-is C<warnings_are {foo()} [], "no warnings in">.
+Another way to say that there aren't ary warnings in the block
+is C<warnings_are {foo()} [], "no warnings">.
If you want to test for a warning given by carp,
-You have to write something like:
+you have to write something like:
C<warning_is {carp "msg"} {carped => 'msg'}, "Test for a carped warning">.
-The test will fail,
+The test will fail
if a "normal" warning is found instead of a "carped" one.
Note: C<warn "foo"> would print something like C<foo at -e line 1>.
This method ignores everything after the at. That means, to match this warning
you would have to call C<warning_is {warn "foo"} "foo", "Foo succeeded">.
-If you need to test for a warning at an exactly line,
-try better something like C<warning_like {warn "foo"} qr/at XYZ.dat line 5/>.
+If you need to test for a warning at a particular line number,
+try something like C<warning_like {warn "foo"} qr/at XYZ.dat line 5/>.
-warning_is and warning_are are only aliases to the same method.
+warning_is and warnings_are are only aliases to the same method,
+simply in order to make for more readable method names.
So you also could write
C<warning_is {foo()} [], "no warning"> or something similar.
-I decided me to give two methods to have some better readable method names.
A true value is returned if the test succeeds, false otherwise.
@@ -70,32 +70,33 @@
=item warnings_are BLOCK ARRAYREF, TEST_NAME
Tests to see that BLOCK gives exactly the specificated warnings.
-The test fails if the BLOCK warns a different number than the size of the ARRAYREf
-would have expected.
+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 tests for carped warnings look that way:
+If you want more than one test for carped warnings, try this:
C<warnings_are {carp "c1"; carp "c2"} {carped => ['c1','c2'];> or
C<warnings_are {foo()} ["Warning 1", {carped => ["Carp 1", "Carp 2"]}, "Warning 2"]>.
-Note that C<{carped => ...}> has always to be a hash ref.
+Note that C<{carped => ...}> always has to be a hash ref.
=item warning_like BLOCK REGEXP, TEST_NAME
-Tests that BLOCK gives exactly one warning and it can be matched to the given regexp.
+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 after the whole warn line,
-which consists in general of "WARNING at __FILE__ line __LINE__".
-So you can check for a warning in at File Foo.pm line 5 with
+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
C<warning_like {bar()} qr/at Foo.pm line 5/, "Testname">.
-I don't know whether it's sensful to do such a test :-(
-However, you should be prepared as a matching with 'at', 'file', '\d'
+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.
-Think to the qr/^foo/ if you want to test for warning "foo something" in file foo.pl.
+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.
@@ -103,7 +104,7 @@
as strings without slashes are reserved for warning categories
(to match warning categories as can be seen in the perllexwarn man page).
-Similar to C<warning_is>,
+As with C<warning_is>,
you can test for warnings via C<carp> with:
C<warning_like {bar()} {carped => qr/bar called too early/i};>
@@ -119,17 +120,18 @@
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,
-wich has a little bit changed to 5.6.1 or earlier versions
-(You can access the internal used tree with C<$Test::Warn::Categorization::tree>,
-allthough I wouldn't recommend it)
+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
+C<$Test::Warn::Categorization::tree>,
+although it isn't recommended).
Thanks to the grouping in a tree,
-it's simple possible to test for an 'io' warning,
-instead for testing for a 'closed|exec|layer|newline|pipe|unopened' warning.
+it's possible to test simply for an 'io' warning,
+instead of testing for a 'closed|exec|layer|newline|pipe|unopened' warning.
-Note, that warnings occuring at compile time,
-can only be catched in an eval block. So
+Note that compile-time warnings
+can only be caught in an eval block. So
warning_like {eval q/"$x"; $x;/}
[qw/void uninitialized/],
@@ -138,9 +140,8 @@
will work,
while it wouldn't work without the eval.
-Note, that it isn't possible yet,
-to test for own categories,
-created with warnings::register.
+Note also that it isn't yet possible
+to test for categories you created yourself with C<warnings::register>.
=item warnings_like BLOCK ARRAYREF, TEST_NAME
@@ -160,7 +161,7 @@
{carped => qr/bar warning/i},
'io'
],
- "I hope, you'll never have to write a test for so many warnings :-)";
+ "I hope you'll never have to write a test for so many warnings :-)";
=back
@@ -174,27 +175,28 @@
=head1 BUGS
Please note that warnings with newlines inside are making a lot of trouble.
-The only sensful way to handle them is to use are the C<warning_like> or
-C<warnings_like> methods. Background for these problems is that there is no
-really secure way to distinguish between warnings with newlines and a tracing
+The only sensible way to handle them is to use the C<warning_like> or
+C<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 it's own warn handler,
+If a method has its own warn handler,
overwriting C<$SIG{__WARN__}>,
my test warning methods won't get these warnings.
-The C<warning_like BLOCK CATEGORY, TEST_NAME> method isn't extremely tested.
-Please use this calling style with higher attention and
-tell me if you find a bug.
+The C<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.
=head1 TODO
Improve this documentation.
The code has some parts doubled - especially in the test scripts.
-This is really awkward and has to be changed.
+This is really awkward and must be changed.
-Please feel free to suggest me any improvements.
+Please feel free to suggest improvements.
=head1 SEE ALSO
@@ -359,7 +361,7 @@
$Tester->diag( "found warning: $_" );
}
}
- $Tester->diag( "didn't found a warning" ) unless @_;
+ $Tester->diag( "didn't find any warning" ) unless @_;
}
sub _diag_exp_warning {
