我想测试我在Perl中编写的脚本,并专门检查它写入文件的输出。我前一段时间写过这篇文章并且不希望将其修改为将其转换为模块的程度,但希望在添加一些小的功能更改之前对其进行回归测试。
到目前为止我已经
了use Test::Command tests => 10;
exit_is_num($cmd, 0);
....
但该命令会生成一些文件,我想检查这些文件是否与我预期的相同(相等或匹配一些正则表达式)。 任何建议
答案 0 :(得分:2)
好的,我会选择蛮力的DIY方法(但是有可能已经有一些带有文件检查API的测试模块 - 我从来没有像我们需要的那样灵活/通用,并且自己编写并且从未感觉到引人注目需要更深入地搜索:)。
我将描述一个相当通用的测试设置,您可能只需要/只需要非常具体的文件测试方面。
在这种情况下,我们所做的实际上是您的功能规范,作为整体测试框架的一部分:
拥有一个包含两种方法(包括其他方法)的测试库 - test_file_identical()
和test_grep_file()
。如果你需要帮助写这两个,请发表评论,我会提供一些提示(我们使用不同的比较器,包括-e
的组合,各种stat
属性的比较,比较测试的内容字符串文件与基准文件通过File::Slurp
获得并执行文件的grep
,逐行或通过小文件的slurped内容,包括将按摩grep结果与基准文件进行比较。
将测试用例组织到子目录(或tarball)中,每个测试一个,每个测试包含2个目录 - 输入文件和预期的输出文件。
让测试引擎脚本循环遍历测试用例(对于我们来说,这是由Perl数据结构进行元描述的,或者更好的是XML文件,因此业务分析师可以根据需要调整它们)。
如果测试用例指定测试需要匹配(完全或通过grep),测试引擎会找到适当的文件(硬编码名称,或通过测试用例中指定的名称模式),应用这些文件第一个要点中提到的测试方法
答案 1 :(得分:1)
测试没有什么神奇之处。阅读文件,检查他们是否有正确的内容。沼泽简单。
open my $fh, $file;
my $have = join '', <$fh>;
is $have, <<'WANT', "contents of $file";
The quick brown fox
jumped over the lazy grey dog.
WANT
没有什么可以破坏的。 Test::File::Contents将为您提供一些实用功能,因此您无需反复写入。
如果您正在测试一堆文件,则可以驱动流程数据。
my %file_tests;
$file_tests{"expected_filename"} = <<'WANT';
Expected content
WANT
... and so on ...
for my $file (keys %file_tests) {
my $want = $file_tests{$file};
file_contents_is($file, $want, "contents of $file");
}
如果内容很大,您可能希望将预期的输出粘贴到文件中并使用files_contents_identical()。
最后,如果你想确保程序只生成你期望的文件并且没有偏离,请创建一个临时目录,chdir,从那里运行程序,并检查目录中是否只包含你期望的文件。我将把它作为读者的练习。