Question

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

例如，我写了这样的东西（通过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核心功能的人都可以帮到我。脚本（未模块化）无法正确测试？

此致

Answer 1

一个重要的区别是：如果有人要编辑（bugfix或新功能）你的'script.pl'文件，那么在当前状态下运行你的'script.t'文件会提供有关新状态的任何有用信息'script.pl'？对于这种情况，您必须{。1}}或include .pl文件，而不是有选择地复制/粘贴摘录。

在最好的情况下，您可以模块化地设计软件并计划测试。如果你想在事后测试单片脚本，我想你可以在use之后编写一个include你的主程序的测试脚本，并且至少要测试子程序...

Answer 2

如果将程序设置为modulino，则可以像模块一样测试程序。我已经在整个地方写过这个，但最引人注目的是 Mastering Perl 。你现在可以read Chapter 18 for online for free，因为我正在公开第二版。：）

Answer 3

不进行验证与验证等，测试是指验证其他行为的行为，行为符合要求并且不会发生某些不良行为的任何活动。测试的范围可以是有限的（只能验证一些所需的行为），或者它可以是全面的（验证大部分或全部所需或所需的行为），可能需要通过大量的步骤或组件来进行测试。在我看来，你的语境中的“确认”一词是另一种说“有限范围测试”的方式。当然它并没有完全验证你的测试行为，但它做了些什么。直接回答手头的问题：我认为调用你所做的“确认”只是语义问题。

Perl：测试的定义是什么？

3 个答案: