这里我给出了需要进行单元测试的子程序的伪代码。
sub get_detail_team(param1,param2){
my $dbh = connect to databasehandle
my sql = get_sql_details(param1,param2)
my $sth = $dbh->prepare($sql)
$sth->execute()
my $result = $sth->fetchall_arrayref();
return get_html_content($result,prama)
}
get_sql_details()和get_html_content()也是同一个包中的子例程。 我们如何对get_detail_team()函数进行单元测试?
我尝试使用此Test::Mockmodule
,但没有得到确切的结果。
答案 0 :(得分:5)
我认为这不适合嘲笑。
第一个问题是get_detail_team
做两件事,它获取数据和它格式化它。格式化数据比数据结构更难测试。将格式与功能分开可以使测试更加容易,并且可以更轻松地添加更多格式化程序。一个提取方法稍后重构......
sub get_detail_team_data($param1, $param2) {
my $dbh = connect_to_database;
my $sql = get_sql_details($param1, $param2);
my $sth = $dbh->prepare($sql)
$sth->execute();
return $sth->fetchall_arrayref();
}
sub get_detail_team($param1, $param2) {
my $detail_team = get_detail_team_data($param1, $param2);
return get_html_content($detail_team);
}
现在我们可以专注于测试数据。查看get_detail_team_data
它只是get_sql_details
周围的薄包装。要测试get_sql_details
,您希望获取SQL,并查看它是否取得了get_detail_team_data
所属的数据。您也可以只使用get_detail_team_data
的基本集成测试来专注于get_sql_details
上的测试。这留下了数据库连接的问题。
我并不喜欢嘲笑所有外部服务都被删除了。如果你要编写SQL,你需要一个SQL数据库来运行它,否则你并没有真正测试它的功能。我将假设存在一个测试数据库,其模式与生产数据库相匹配。您的测试可以使用他们喜欢的任何数据填充它,并在脚本结束时回滚。
最简单的方法是编写connect_to_database
,以便它将一个测试环境变量用于连接到测试数据库。更好的是拥有一个环境变量来控制整个系统查找整个测试套件可以利用的配置信息的位置。
get_detail_team
不值得多测试,它只是一个薄的包装。为它编写基本的集成测试,并专注于测试get_html_content
,你可以传递一个数据结构。