Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
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 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/".

	   Warn	messages with a	trailing newline (like "warn "foo\n"") don't
	   produce the "at -e line 1" message by Perl. Up to Test::Warn	0.30
	   such	warning	weren't	supported by "warning_is {warn "foo\n"}
	   "foo\n"". Starting with version 0.31	they are supported, but	also
	   marked as experimental.

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

	   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 occurring at compile time, 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, 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 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 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 must be changed.

       Please feel free	to suggest improvements.

SEE ALSO
       Have a look to the similar modules: Test::Exception, 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.24.1			  2016-12-23			       Warn(3)

NAME | SYNOPSIS | DESCRIPTION | BUGS AND LIMITATIONS | TODO | SEE ALSO | THANKS | AUTHOR | COPYRIGHT AND LICENSE

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=Test::Warn&sektion=3&manpath=FreeBSD+12.0-RELEASE+and+Ports>

home | help