Question

我有一个单元测试，即使代码中没有错误，也可以在1,000,000（猜测）时间内自发失败1次。这是一个可接受的容忍度还是TDD宣言需要铁拳绝对性？

对于那些感兴趣的人来说，就像这样

stuff = randomCrap.get()
stuff2 = randomCrap.get()
assert(stuff != stuff2)

Answer 1

那么，这真的取决于失败的根源。你知道为什么它失败了吗？如果是这样，您是否尝试隔离该故障以使其不会使单元测试失效？

就个人而言，我会说，如果真的百万分之一，并且你知道它为什么会发生，那么就为这个效果添加评论而不用担心。毕竟，在连续构建中不太可能会给人们带来太大麻烦。当然，如果它真的十分之一，或类似的东西，这是一个非常不同的事情。

我至少会尝试来删除不正确的来源。首先，它表明您的测试不可重复。 有时候没关系 - 有一些随机性来源很难提取 - 但我会尽量不去做。如果你已经尝试并达到了一个区块，那么务实的事情就是记录它并继续前进，IMO。

Answer 2

问题不在于“TDD是否允许我允许偶尔失败的测试？”但是，相反：“我的系统要求是否允许偶尔出现故障？”这是一个只有你能回答的问题。

从TDD的角度来看，偶尔失败的测试是笨拙的 - 你不知道，当它们失败时，是否因为这是一个罕见的允许失败，或者是否因为你的代码被打破是不可接受的办法。所以偶尔失败的测试对你来说远没有那么有用。

如果您的要求是在一百万次中有一次不同的行为，那么您应该测试该要求。测试一般情况，不是使用随机数，而是使用有效输入的有意义子集。使用应该带来特殊行为的值来测试特殊情况。

Answer 3

您对此错误发生前的频率有何要求？

您是否感觉舒适，以及您的功能用户，以及正在发生的事情？

您可能希望确定已写下您的随机生成将重复，有时是重复请求。

对我而言，这是一个更令人不安的部分，它可能会像你上面所说的那样发生，我认为这是值得研究的。

Answer 4

你绝对必须使用随机数据吗？您是否正在测试一个返回两个不同随机值的系统？否则创建一个存根。单元测试应该是100％可重复的，例如使用文件系统的线程时这很难做到，但这就是存根的用途。

Answer 5

如果代码中没有错误，单元测试不会失败。有一个错误，无论是与时间，网络等有关......你还没有想到它。一旦你搞清楚了，你就学到了一些你不知道的东西。 +1给你。

如果不修复真正的问题是心理问题。只要系统中发生奇怪/随机/无法解释的事情，该方法就会受到指责。当你想到它时，最好立即修复红鲱鱼。

而且仅供参考，随机性并不意味着独特。

Answer 6

你的测试断言stuff1 从不等于stuff2，但看到测试失败偶尔意味着这不是真的。

你可以通过花费一百万个样本并断言相等的频率小于10来断言stuff1 偶尔等于stuff2，但是这仍然会偶尔失败 - 但也许更不常见的是可以接受的。

你可能会更好：

stuff = 4 stuff2 = 5 assert(stuff != stuff2)

您可以非常肯定上述代码的执行次数与原始代码的执行次数相差一百万次 - 但您确定此代码每次都会通过！