问TDD -什么时候可以写一个不失败的测试？

EN

首先编写失败的测试，然后让它们运行，有两个原因；

第一个是检查测试是否真的是在测试你写它的目的。您首先检查它是否失败，然后更改代码以使测试运行，然后检查它是否运行。这看起来很愚蠢，但我有几次为已经运行的代码添加了一个测试，后来才发现我在测试中犯了一个错误，使它始终运行。

第二个也是最重要的原因是防止你写太多的测试。测试反映了您的设计，而您的设计反映了您的需求和需求更改。当这种情况发生时，你不会想要重写很多测试。一个很好的经验法则是，每个测试都因为一个原因而失败，并且只有一个测试因为这个原因而失败。TDD试图通过对代码库中的每个测试、每个功能和每个更改重复标准的红-绿-重构循环来强制执行这一点。

但当然，规则是用来打破的。如果你首先记住为什么要制定这些规则，你就可以灵活地使用它们。例如，当您发现您有测试多个东西的测试时，您可以将其拆分。实际上，您已经编写了两个以前从未见过失败的新测试。分解代码，然后修复代码，使新的测试失败，这是一种双重检查的好方法。

我怀疑没有人会建议我浪费时间来实现一个不稳定的排序算法，只是为了测试测试用例，然后重新实现合并排序。你多久会遇到一次类似的情况，你会怎么做？

那就让我来推荐吧。:)

所有这些东西都是你一方面花费的时间，另一方面你减少或减轻的风险，以及你获得的理解之间的权衡。

继续假设的例子。

如果“稳定性”是一个重要的属性/特性，并且您没有通过使其失败来“测试测试”，那么您节省了做这项工作的时间，但却招致了测试是错误的并且始终是绿色的风险。

另一方面，如果你通过破坏特性并看着它失败来“测试测试”，你就降低了测试的风险。

而且，通配符是，您可能会获得一些重要的知识。例如，当试图编写一个“糟糕”的排序并导致测试失败时，您可能会更深入地考虑正在排序的类型的比较约束，并发现您使用"x==y“作为排序的等价类谓词，但实际上"!(x

所以我会说“花额外的时间让它失败，即使这意味着故意破坏系统，只是为了在屏幕上看到一个红点”，因为虽然每一个小的“转移”都会产生一些时间成本，但偶尔一个会为你节省一大笔钱(例如，测试中的一个bug意味着我从来没有测试过我的系统的最重要的属性，或者哦，我们对不等式谓词的整个设计都搞砸了)。这就像玩彩票一样，除了从长远来看，赔率对你有利；每周你花5美元买彩票，通常你会输，但每三个月你就会中1000美元的大奖。

让测试首先失败的一个最大的好处是，它可以确保您的测试真正测试了您的想法。你可以在你的测试中有一些细微的bug，导致它根本不能真正测试任何东西。

例如，我曾经在我们的C++代码库中看到有人签入了测试：

assertTrue(x = 1);

显然，他们没有编程，所以测试首先失败了，因为这根本不会测试任何东西。