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

Question

据我了解，在TDD中，您必须先编写一个失败的测试，然后编写代码使其通过，然后进行重构。但是，如果您的代码已经解决了您要测试的情况，该怎么办？

例如，假设我正在TDD'排序算法(这只是假设)。我可能会针对两种情况编写单元测试:

输入= 1，2，3
输出= 1，2，3

输入= 4，1，3，2
输出= 1，2，3，4

等等...

为了使测试通过，我最后使用了一个快速的“n脏泡沫排序”。然后，我将其重构并替换为更有效的合并排序算法。后来，我意识到我们需要一种稳定的排序方式，因此我也为此编写了一个测试。当然，测试不会失败，因为合并排序是一种稳定的排序算法!无论如何，我仍然需要此测试，以防有人再次对其进行重构以使用其他可能不稳定的排序算法。

这是否打破了始终编写失败测试的TDD口号？我怀疑有人会建议我浪费时间实现不稳定的排序算法，只是为了测试测试用例，然后重新实现合并排序。您多久遇到一次类似情况，您会怎么做？

Answer 1

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

首先是检查测试是否实际上在测试您编写的内容。您首先检查它是否失败，然后更改代码以进行测试运行，然后检查它是否运行。看起来很愚蠢，但是我有好几次为已经运行的代码添加了一个测试，以便以后发现我在测试中犯了一个错误，使它始终可以运行。

第二个也是最重要的原因是防止您编写过多的测试。测试反射(reflect)了您的设计，而设计则反射(reflect)了您的需求和需求变更。发生这种情况时，您不需要重写很多测试。一个好的经验法则是，使每个测试仅出于一个原因而失败，并且仅使一个测试因该原因而失败。 TDD尝试通过对代码库中的每个测试，每个功能和每个更改重复标准的红绿重构周期来强制执行此操作。

但是当然要打破规则。如果您牢记为什么首先要制定这些规则，则可以灵活地使用它们。例如，当您发现自己的测试可以测试多项功能时，可以将其拆分。实际上，您已经编写了两个从未见过失败的新测试。破坏然后修复代码以查看新测试失败是重新检查事情的一种好方法。