7

问这个问题我觉得有点羞耻，但我很好奇。我最近编写了一个脚本（没有在模块中组织代码），它读取商店的日志文件并将信息保存到数据库中。

例如，我写了这样的东西（通过 Richard Huxton）：

while (<$infile>) {
    if (/item_id:(\d+)\s*,\s*sold/) {
        my $item_id = $1;
        $item_id_sold_times{$item_id}++;
    }
}
my @matched_items_ids = keys %item_id_sold_times;
my $owner_ids =
  Store::Model::Map::ItemOwnerMap->fetch_by_keys( \@matched_item_ids )
  ->entry();
for my $owner_id (@$owner_ids) {
    $item_id_owner_map{$owner_id}++;
}

比如说，这个脚本叫做 script.pl。在测试文件时，我制作了一个文件script.t，不得不在script.t中重复一些script.pl块。复制粘贴相关代码部分后，我会进行如下确认：

is( $item_id_sold_times{1}, 1, "Number of sold items of item 1" );
is( $item_id_owner_map{3},  8, "Number of sold items for owner 3" );

等等等等。

但有人指出，我写的不是测试。这是一个确认脚本。一个好的测试包括用模块编写代码，编写一个脚本来启动模块中的方法，并为模块编写一个测试。

这让我想到了软件工程中最广泛使用的测试的定义是什么。也许你们中的一些甚至测试过 Perl 核心功能的人可以帮助我。无法正确测试脚本（未模块化）？

问候

4

3 回答 3

10

一个重要的区别是：如果有人要编辑（错误修复或新功能）您的“script.pl”文件，在当前状态下运行您的“script.t”文件会提供有关新“脚本”状态的任何有用信息。吗？为此，您必须include使用use.pl 文件，而不是选择性地复制/粘贴摘录。

在最好的情况下，您可以模块化设计软件并计划测试。如果你想在事后测试一个整体脚本，我想你可以编写一个测试脚本，它include是你的主程序，exit()并且至少有要测试的子例程......

于 2013-06-12T02:40:33.383 回答
4

如果将程序设置为模数，则可以像模块一样测试程序。我到处都写过这方面的文章，但最著名的是在Mastering Perl中。由于我正在公开编写第二版，您现在可以在线免费阅读第 18 章。:)

于 2013-06-12T04:13:50.050 回答
2

在不涉及验证与验证等的情况下，测试是验证其他事物的行为、行为符合要求以及某些不良行为不会发生的任何活动。测试的范围可以是有限的（仅验证少数所需的行为），也可以是全面的（验证大部分或全部所需或所需的行为），可能需要大量的测试步骤或组件才能做到这一点. 在我看来，您的上下文中的“确认”一词是“有限范围测试”的另一种说法。当然，它并不能完全验证您的测试行为，但它确实有所作为。直接回答手头的问题：我认为将您所做的称为“确认”只是语义问题。

于 2013-06-12T02:25:27.620 回答