规范变更时的测试驱动开发

Question

这些天来，我的任务是做一个实际上违反了以前规范的更改，这对我来说是相当普遍的。我知道TDD背后的主要想法之一是拥有一个套件来验证您的所有更改实际上并没有破坏任何东西，但是当您需要做的更改实际上必须破坏单元测试时，您会做什么呢？

如何进行测试驱动开发是一个类似的，相关的问题，但它与我的问题不同。在我的例子中，我已经进行了测试，并且规范已经改变了。在这个问题上，“任择议定书”尚未进行测试。

Answer 1

TDD的宣传周期是编写测试，直到它们失败，然后黑客攻击代码，直到它们再次通过，然后重构，同时保持所有测试的成功。

当规范更改时，您将需要删除将验证违反新规范的旧测试，并编写将验证新规范的新测试。

Answer 2

TDD "by the book“有一个特定的循环，并且对于更改规范，这个周期最好是这样的：

1. 根据新的规范编写一个测试(->“红色”)
2. 更改SUT (“要测试的主体”)以匹配新的测试；根据更改的不同，这可能会破坏一些旧的测试(->新测试变为“绿色”，但旧测试变为“红色”)。
3. 如果可以根据新规范修改旧测试以测试SUT，则更改它们。或者，如果不可能，删除它们(->“绿色”)
4. 从步骤1开始重复，直到有足够的测试来验证整个规范，并且SUT实现了它。

当然，在现实世界中，您将尽量避免在步骤1中添加一个测试会导致步骤3中删除100个现有的测试。如果是这样的话，测试会显示您的原始设计不够进化，或者您的测试不够干燥，或者规范更改太大，以至于您实际上不得不删除大部分原始的SUT并编写一个新的测试。