Silence a warning in TAP

My code has a test for a bad API call, fortunately that code results in a warning from the module itself. But when I'm testing the failed API call I want to not see the warning in TAP.

t/01-pass.t .............. ok
t/02-fail.t .............. ok
t/03-noversion.t ......... ok
t/04-no-file.t ........... ok
Use of uninitialized value $file in concatenation (.) or string at /home/xenoterracide/projects/Test-Version/lib/Test/Version.pm line 29.
t/05-file-not-defined.t .. ok
# unsorted oks: 001
t/06-all.t ............... ok
All tests successful.
Files=6, Tests=37,  1 wallclock secs ( 0.04 usr  0.02 sys +  0.35 cusr  0.04 csys =  0.45 CPU)
Result: PASS

Here's the actual code

#!/usr/bin/perl
use 5.006;
use strict;
use warnings;
use Test::Tester tests => 7;
use Test::Version qw( version_ok );

check_test(
    sub {
        version_ok; # correct call version_ok( $fil开发者_Python百科e )
    },
    {
        ok => 0,
        name => 'check version in ',
        diag => 'FILE_NOT_DEFINED',
    },
    '$file not defined'
);

is there any way to squelch the warning and prevent to prevent it from ending up in TAP (outside of no warnings in the original module).

You're possibly looking for Test::Warn. It's easy to use:

use strict;
use warnings;
use Test::More;
use Test::Warn;
# You might also find the following modules interesting:
# use Test::Exception;
# use Test::NoWarnings;

sub bla { warn 'bla' }

warning_is { bla() } 'bla';
done_testing;

So you're transforming the warning from a nuisance into something expected.

If this is not what you want, then take a look at IO::CaptureOutput or - de préférence, according to the author of both modules, David Golden - at Capture::Tiny.

You could also code everything by hand redirecting STDERR to buffer for the time you're making the call that'll emit the warning.

local $SIG{__WARN__} = sub {};

will silence warnings temporarily.

Another warning-related module to consider is Test::NoWarnings. This checks that your code produces no warnings, and will fail a test if not. You can ignore known warnings, such as the OP's, assuming that is the desired behaviour (at $work we ignore warnings from a handful of 'noisy' CPAN modules, such as PDF::API2). It can

In general I'd agree with Schwern though, and try and fix warnings rather than a blanket $SIG{__WARN__} override. One of the main benefits of tests is catching errors introduced when other code is changed - your test file is not just checking that the code you've just written is ok, but that the code you've written will still be ok in the future when CPAN modules and the rest of your app will have been updated.