我正在开展一个项目，我第一次应用TDD方法。 这一切都很顺利，直到需求发生变化，我不得不改变一些类行为和API 改变一个阶级的行为最终导致改变其他一些行为。 我不知道如何从测试端开始这个过程，所以我开始更改代码。 我最终在测试代码中遇到了很多编译错误，在我修复它们之后，有些错误没有通过。 但问题是，我甚至不知道这些测试是否涵盖了以前的测试。 在写作时，我添加了测试时，我逐个添加了生产代码， 但现在看来我必须检查所有改变并验证的测试类：
我做错了什么？ 这是进行此类重构工作的方法还是有更好的方法？
答案 0 :(得分：2)
A）重构：改进代码结构，而不修改其外部可观察行为。 （这里外部意味着被测组件的外部）
既然你说你正在修改API，这意味着改变了行为，所以你所做的并不是重构。这不是批评，只是一种观察。
如果您真正进行了重构（不改变外部可观察行为），则不需要更改测试。如果它们仍然需要更改，那么它们与组件的实现紧密耦合（与其行为相反）。
B）事后看来，您现在可以看到如何从测试方面推动这些变化吗？您是否完全理解推动变革的要求？
我认为自动化测试是系统文档。如果要求发生变化，那么我会查找受影响的文档部分，并对其进行更改以反映新要求。然后测试很可能会失败，但现在我有驱动程序来改变实现。如果他们不会失败，那么也许一切都很好;）
C）如果您发现自己在测试中的多个位置进行了相同的更改，也许您应该应用DRY（不要重复自己）方法。将重复的代码片段提供的功能本地化在一个地方（类/方法）。利用Builder或Object Mother模式将测试与数据结构的偶然变化隔离开来....等等。