[SCM] Debian packaging of libtest-warn-perl branch, master, updated. upstream/0.24-70-g2db5327
gregor herrmann
gregoa at debian.org
Fri Jun 7 22:31:05 UTC 2013
The following commit has been merged in the master branch:
commit dd764d41bd25dcdde20f1a98e1cc69d5706f0e0a
Author: gregor herrmann <gregoa at debian.org>
Date: Sat Jun 8 00:26:11 2013 +0200
Refresh language.patch, partly merged upstream.
diff --git a/debian/patches/language.patch b/debian/patches/language.patch
index b89a83e..99c62eb 100644
--- a/debian/patches/language.patch
+++ b/debian/patches/language.patch
@@ -3,18 +3,11 @@ Description: Patch from Era Eriksson to clean up some manpage language
Bug-Debian: #322351
Forwarded: https://rt.cpan.org/Ticket/Display.html?id=49519
Reviewed-by: Nicholas Bamber <nicholas at periapt.co.uk>
-Last-Update: 2010-09-23
+Reviewed-by: gregor herrmann <gregoa at debian.org>
+Last-Update: 2013-06-08
+
--- a/Warn.pm
+++ b/Warn.pm
-@@ -15,7 +15,7 @@
- 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';
@@ -31,9 +31,9 @@
A good style of Perl programming calls for a lot of diverse regression tests.
@@ -23,104 +16,43 @@ Last-Update: 2010-09-23
+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 L<Test::More> manpage,
++If you are not already familiar with the L<Test::More> manpage,
now would be the time to go take a look.
=head2 FUNCTIONS
-@@ -42,29 +42,28 @@
-
- =item warning_is BLOCK STRING, TEST_NAME
-
--Tests that BLOCK gives exactly the one specified warning.
--The test fails if the BLOCK warns more then one times or doesn't warn.
-+Tests that BLOCK gives the specified warning exactly once.
-+The test fails if the BLOCK warns more than once or does not warn at all.
- If the string is undef,
- then the tests succeeds if the BLOCK doesn't give any warning.
--Another way to say that there aren't any warnings in the block,
--is C<warnings_are {foo()} [], "no warnings in">.
-+Another way to say that there are no 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:
+@@ -49,7 +49,7 @@
+ Another way to say that there are no warnings in the block
+ is C<warnings_are {foo()} [], "no warnings">.
+
+-If you want to test for a warning given by Carp,
+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 =E<gt> 'msg'}, "Test for a carped warning">.
--The test will fail,
--if a "normal" warning is found instead of a "carped" one.
-+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
-+This method ignores everything after the "at". Thus 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/>.
-+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.
- So you also could write
- C<warning_is {foo()} [], "no warning"> or something similar.
--I decided to give two methods to have some better readable method names.
-+I decided to give two methods the same name to improve readability.
-
- A true value is returned if the test succeeds, false otherwise.
-
-@@ -74,32 +73,32 @@
- =item warnings_are BLOCK ARRAYREF, TEST_NAME
-
- Tests to see that BLOCK gives exactly the specified 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 if 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 => ...}> must always 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 line,
-+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
+ The test will fail if a "normal" warning is found instead of a "carped" one.
+@@ -95,10 +95,10 @@
+ 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 is not sensible to perform such a test;
-+however, you should be aware that matching on a sweeping regular expression
++Perhaps it is not sensible to perform such a test;
++however, you should be aware that matching on a sweeping regular expression
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.
++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.
-@@ -107,7 +106,7 @@
+@@ -106,7 +106,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>,
++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};>
-@@ -123,17 +122,17 @@
+@@ -122,17 +122,17 @@
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.
@@ -128,46 +60,46 @@ Last-Update: 2010-09-23
-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>,
-although I wouldn't recommend it)
-+Note that they have the hierarchical structure from perl 5.8.0,
-+you can access the internal hierarchy with
-+C<$Test::Warn::Categorization::tree>,
-+although it isn't recommended).
++Note that they have the hierarchical structure from perl 5.8.0,
++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.
++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
++Note that compile-time warnings
++can only be caught in an eval block. So
warning_like {eval q/"$x"; $x;/}
[qw/void uninitialized/],
-@@ -142,9 +141,8 @@
+@@ -141,9 +141,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>.
++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
-@@ -164,7 +162,7 @@
+@@ -163,7 +162,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 :-)";
++ "I hope you'll never have to write a test for so many warnings :-)";
=item warnings_exist BLOCK STRING|ARRAYREF, TEST_NAME
-@@ -189,32 +187,32 @@
+@@ -188,19 +187,19 @@
=head1 BUGS
@@ -178,7 +110,7 @@ Last-Update: 2010-09-23
+Please note that warnings with newlines inside are very awkward.
+The only sensible way to handle them is to use the C<warning_like> or
+C<warnings_like> methods. The background is that there is no
-+really safe way to distinguish between warnings with newlines and a
++really safe way to distinguish between warnings with newlines and a
stacktrace.
-If a method has it's own warn handler,
@@ -189,24 +121,17 @@ Last-Update: 2010-09-23
-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 take note if you use this this calling style,
-+and report any bugs you find.
++The C<warning_like BLOCK CATEGORY, TEST_NAME> method isn't fully tested.
++Please take note 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.
+@@ -213,7 +212,7 @@
=head1 SEE ALSO
--Have a look to the similar L<Test::Exception> module. Test::Trap
+-Have a look to the similar modules: L<Test::Exception>, L<Test::Trap>.
+Have a look to the similar L<Test::Exception> module. L<Test::Trap>
=head1 THANKS
--
Debian packaging of libtest-warn-perl
More information about the Pkg-perl-cvs-commits
mailing list