:: RootR ::  Hosting Order Map Login   Secure Inter-Network Operations  
 
Test::Warn(3pm) - phpMan

Command: man perldoc info search(apropos)  


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



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 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";

         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 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
           are no 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". Thus 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 the same name to improve readability.

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

       warning_like BLOCK REGEXP, TEST_NAME
           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 if the BLOCK doesn't give any warning.

           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 "warning_like {bar()} qr/at Foo.pm line 5/, "Testname"".
           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.  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.

       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.  Also see "BUGS
           AND LIMITATIONS".

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

       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 AND LIMITATIONS
       Category check is done as qr/category_name/. In some case this works, like for category
       'uninitialized'. For 'utf8' it does not work. Perl does not have a list of warnings, so it
       is not possible to generate one for Test::Warn.  If you want to add a warning to a
       category, send a pull request. Modifications 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 very awkward.  The only sensible way to
       handle them is to use the "warning_like" or "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 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 take note
       if you use this this calling style, and report any bugs you find.

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

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-2014 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.18.2                                2014-04-06                                  Warn(3pm)


/man
rootr.net - man pages