TDD 和重构“被测系统”

Question

我正在开展一个项目，在该项目中我首次应用了 TDD 方法。 一切都很顺利，直到需求发生变化，我不得不改变一些类的行为和 API 改变一个阶级的行为最终会导致改变其他几个阶级的行为。 我不知道如何从测试端开始这个过程，所以我开始更改代码。 我最终在测试代码中遇到了很多编译错误，在我修复它们之后有些没有通过。 但问题是，我什至不知道测试是否涵盖了他们以前涵盖的内容。 在编写时，我在添加测试时逐段添加生产代码， 但现在看来我必须检查所有更改并验证的测试类：

1. 每个测试仍然相关
2. 没有遗漏测试
3. 测试不会产生任何假阳性或假阴性

TDD 应该在重构时给我一个安全网。不是吗？ 正如它目前在我的情况下出现的那样，它并没有给我。

我做错了什么？ 这是进行此类重构工作的方法还是有更好的方法？

Answer 1

A) 重构：在不修改其外部可观察行为的情况下改进代码结构。 （这里的外部是指被测组件的外部）

由于您说您正在修改 API，这意味着要更改行为，因此您所做的并不是重构。这不是批评，只是观察。

如果你真的在重构（不改变外部可观察的行为），那么测试应该不需要改变。如果它们仍然需要更改，那么它们与组件的实现耦合太紧密（与其行为相反）。

B) 事后看来，您现在能看出您是如何从测试方面推动这些变化的吗？您是否完全了解推动变更的需求？

我认为自动化测试是系统文档。如果需求发生变化，那么我会查找受影响的文档部分并对其进行更改以反映新的需求。测试很可能会失败，但现在我有驱动程序来更改实现。如果他们没有失败，那么也许一切都很好；）

C) 如果您发现自己在测试中的多个位置进行了相同的更改，也许您应该应用 DRY（不要重复自己）方法。将重复的代码片段提供的功能本地化在一个地方（类/方法）。利用 Builder 或 Object Mother 模式将您的测试与数据结构的偶然更改隔离开来……等等。