1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
Description: Patch from Era Eriksson to clean up some manpage language
Bug-Debian: #322351
Forwarded: https://rt.cpan.org/Ticket/Display.html?id=49519
Author: Jay Bonci <jaybonci@debian.org>
Reviewed-by: gregor herrmann <gregoa@debian.org>
Last-Update: 2014-04-06
--- a/Warn.pm
+++ b/Warn.pm
@@ -31,9 +31,9 @@
A good style of Perl programming calls for a lot of diverse regression tests.
-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 L<Test::More> manpage,
now would be the time to go take a look.
=head2 FUNCTIONS
@@ -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:
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.
@@ -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 makes sense 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
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.
@@ -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>,
you can test for warnings via C<carp> with:
C<warning_like {bar()} {carped => qr/bar called too early/i};>
@@ -126,10 +126,10 @@
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 occurring at compile time,
+Note that compile-time warnings
can only be caught in an eval block. So
warning_like {eval q/"$x"; $x;/}
@@ -139,9 +139,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
@@ -161,7 +160,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 :-)";
=item warnings_exist BLOCK STRING|ARRAYREF, TEST_NAME
@@ -193,19 +192,19 @@
should be done to %warnings_in_category. You should look into perl source to check
how warning is looking exactly.
-Please note that warnings with newlines inside are making a lot of trouble.
-The only sensible 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
+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
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 take note if you use this this calling style,
+and report any bugs you find.
=head1 TODO
@@ -218,7 +217,7 @@
=head1 SEE ALSO
-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
|
