1

我正在为我们的部分代码库使用基于Test::More的单元测试，该代码库按顺序加载我们所有的内部模块use_ok()。我想让警告对单元测试来说是致命的，这样我们就可以更容易地捕捉到回归。

这里建议我使用Test::NoWarnings，实际上这似乎是我正在寻找的。

脚本在这里：

#!/usr/bin/perl -w
use File::Find;
use File::Spec;
use Test::More;
use Test::NoWarnings;


# Determine the filepaths of every .pm file in the lib directory
my @files;
File::Find::find(
    sub
    {
        if (/\.pm$/)
        {
            push(@files, $File::Find::name);
        }
    },
    "$ENV{'CODE_ROOT'}/lib"
);
done_testing(scalar(@files) + 1);

use lib "$ENV{'CODE_ROOT'}/lib";
foreach my $file (@files)
{
    # <code removed for brevity: format file name into Module::Hierarchy::For::Use>
    use_ok($includeString);
}

1;

我遇到过一些EXPORT()不同模块编辑的子例程引发重新定义警告的情况，但这些警告没有被Test::NoWarnings模块捕获。相反，由于小写属性声明引起的警告被正确捕获。

需要明确的是，我已经阅读了有关使用EXPORT()vsEXPORT_OK()的警告，并且正在处理警告的来源。我特别想知道我对 的行为的假设是否Test::NoWarnings正确，如果是，我如何更改单元测试以便捕获此类事情。

4

1 回答 1

1

如果你想让警告变得致命，那么打开它怎么样？

use strict;
use warnings FATAL => 'all';

是的，用于warningspragma 的 POD 强烈警告不要使用此选项：

应谨慎使用致命警告，尤其是FATAL => 'all'

和

不鼓励使用 FATAL => 'all'

但我认为在回归或单元测试中使用是一个有效的用例。很长一段时间以来，我一直在我的所有单元和回归测试中使用它，但没有出现意外后果。我认为Test::Warn并且Test::NoWarnings最适合用于捕获模块自身的警告，包括预期的和意外的。

use strict;
use warnings FATAL => 'all';
use Test::More;
use Test::Warn;             # test for our own expected warnings                
require Test::NoWarnings;   # REQUIRE to suppress auto test at program exit     

my $tCnt = 0;
ok(1, "first test");                                               $tCnt++;
warning_like { warn("my warn") } (qr/my warn/), "caught warning";  $tCnt++;
ok(1, "made it to the end");                                       $tCnt++;
Test::NoWarnings::had_no_warnings();                               $tCnt++;

done_testing($tCnt);

如果你抛出一个像length("123");(void context) 这样的语句，编译时警告将立即启动你并FATALS => 'all'生效。没有它，所有的测试都会运行并通过，没有任何潜在问题的迹象。

于 2018-03-30T20:52:32.463 回答