Страницы справочника OS X

Эта страница руководства для  версии 10.9 Mac OS X

Читать страницы руководства

Warn(3)                              User Contributed Perl Documentation                             Warn(3)



NAME
       Test::Warn - Perl extension to test methods for warnings

SYNOPSIS
         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 warnings for calc 2+2"; # or
         warnings_are  {add(2,2)} [],    "No warnings 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 found 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";

         warnings_exist {...} [qr/expected warning/], "Expected warning is thrown";

DESCRIPTION
       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.

       If you are not already familiar with the Test::More manpage now would be the time to go take a look.

   FUNCTIONS
       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.  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
           "warnings_are {foo()} [], "no warnings in"".

           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 better
           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 better readable method names.

           A true value is returned if the test succeeds, false otherwise.

           The test name is optional, but recommended.

       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.  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: "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 =" ...}> has always to be a hash ref.

       warning_like BLOCK REGEXP, TEST_NAME
           Tests that BLOCK gives exactly one warning and it can be matched to 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
           "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' or similar
           will always pass.  Think to the 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).

           Similar to "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.

       warning_like BLOCK STRING, TEST_NAME
           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 $Test::Warn::Categorization::tree, although I wouldn't
           recommend it)

           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.

           Note, that warnings occuring at compile time, can only be catched 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, that it isn't possible yet, to test for own categories, created with warnings::register.

       warnings_like BLOCK ARRAYREF, TEST_NAME
           Tests to see that BLOCK gives exactly the number of the specified 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 :-)";

       warnings_exist BLOCK STRING|ARRAYREF, TEST_NAME
           Same as warning_like, but will warn() all warnings that do not match the supplied regex/category,
           instead of registering an error. Use this test when you just want to make sure that specific
           warnings were generated, and couldn't care less if other warnings happened in the same block of
           code.

             warnings_exist {...} [qr/expected warning/], "Expected warning is thrown";

             warnings_exist {...} ['uninitialized'], "Expected warning is thrown";

   EXPORT
       "warning_is", "warnings_are", "warning_like", "warnings_like", "warnings_exist" by default.

BUGS
       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 "warning_like" or "warnings_like" methods. Background for these
       problems is that there is no really secure way to distinguish between warnings with newlines and a
       tracing stacktrace.

       If a method has it's 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 extremely tested.  Please use this calling
       style with higher attention and tell me if you find a bug.

TODO
       Improve this documentation.

       The code has some parts doubled - especially in the test scripts.  This is really awkward and has to
       be changed.

       Please feel free to suggest me any improvements.

SEE ALSO
       Have a look to the similar Test::Exception module. Test::Trap

THANKS
       Many thanks to Adrian Howard, chromatic and Michael G. Schwern, who have given me a lot of ideas.

AUTHOR
       Janek Schleicher, <bigj AT kamelfreund.de>

COPYRIGHT AND LICENSE
       Copyright 2002 by Janek Schleicher

       Copyright 2007-2011 by Alexandr Ciornii, <http://chorny.net/>

       This library is free software; you can redistribute it and/or modify it under the same terms as Perl
       itself.



perl v5.12.5                                     2011-02-24                                          Warn(3)