2

使用 test/unit 和 minitest,是否有可能使任何不包含断言的测试失败,或者是否需要猴子补丁(例如,在每次测试执行后检查断言计数是否增加)?

背景:我不应该在没有断言的情况下编写单元测试——至少,assert_nothing_raised如果我正在冒烟测试,我应该使用来表明我正在冒烟测试。

通常我会编写首先失败的测试,但我正在编写一些回归测试。或者,我可以提供不正确的预期值,以查看测试是否在比较预期值和实际值。

4

3 回答 3

1

为了确保单元测试真正验证任何东西,使用了一种称为突变测试的技术。

对于 Ruby,您可以查看Mutant

于 2012-06-20T12:07:06.773 回答
0

我真的不认为在没有断言的情况下强制测试失败真的很有帮助。在测试中拥有一个断言本身并不是一个目标——目标是编写有用的测试

缺少的断言只是表明测试可能没有用。有趣的问题是:如果出现问题,测试会失败吗?. 如果没有,那显然是没用的。

如果您要测试的只是代码不会崩溃,那么assert_nothing_raised围绕它的只是一种注释。但是测试“不爆炸”可能表明测试本身很弱。在大多数情况下,它不会为您提供有关代码的任何有用信息(因为“没有崩溃!= 正确”),那么您为什么首先编写测试呢?另外,我更喜欢一种可以正确爆炸的方法,而不是只返回错误结果的方法。

我发现最好的回归测试来自该领域:敲击你的应用程序(或让你的测试人员去做),然后为你发现的每个问题编写一个失败的测试。修复它,并通过测试。

否则我会测试行为,而不是没有崩溃。在我有“空”测试的情况下(意味着我还没有编写测试代码),我通常会在里面放一个#flunk来提醒我。

于 2010-06-11T16:59:41.163 回答
0

正如 PK 的链接所指出的那样,断言本身的存在并不意味着单元测试是有意义和正确的。我相信没有自动替代仔细思考和意识。

确保测试首先失败是一个好习惯,应该养成习惯。

除了你提到的事情之外,我经常在新测试的断言中设置错误的值,以检查测试是否真的运行和失败。(然后我当然会修复它:-)这比编辑生产代码不那么突兀。

于 2010-06-11T09:12:25.393 回答