TDD与重构“被测试系统”

Question

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

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

TDD应该在重构的时候给我一个安全网。难到不是么？正如目前在我的案例中所显示的那样，它并没有给我这样的答案。

我做错了什么？这是做这种重构工作的方式，还是有更好的方法？

Answer 1

( A)重构:改进代码的结构，而不修改其外部可观察的行为。(这里是被测试组件外部的外部手段)

既然您说您正在修改API，这就意味着要对行为进行更改，所以您所做的不是重构。那不是批评，只是观察。

如果您正在进行真正的重构(而不是改变外部可观察的行为)，那么测试就不应该需要更改。如果它们仍然需要更改，那么它们与组件的实现(相对于其行为)过于紧密地耦合。

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

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

( C)如果你发现自己在测试的多个地方做了同样的改变，也许你应该采用干法(不要重复自己)。将重复代码段提供的功能本地化在一个地方(类/方法)。使用Builder或对象母模式将您的测试与数据结构的附带更改隔离开来。诸若此类。