unit-testing - TDD 中的重构细节

Question

我看过这篇文章

http://codebetter.com/iancooper/2011/10/06/avoid-testing-implementation-details-test-behaviours/

我很困惑

"Code developed in the context of refactoring does not require new tests!"

例如，在重构期间，我决定将一些计算移到一个新类中，该类为我计算阶乘，我使用此类计算一些用户特定的细节。在我的要求中，我永远不会有编写此类的功能，它只是在重构过程中创建的。但是什么时候我应该用测试来覆盖这个类以保证预期的行为？据我所知，我永远不会用测试覆盖这门课，否则我错了？

Answer 1

你是对的。

有两种考虑重构的方法，涵盖两组略有不同的技术。

第一个是做幂等的改变:在一个方法中固定一个小东西，这样最终的结果就不会改变。正如文章中所说，这不需要更改。

第二个(IMO 更有趣)涉及创建新类、更改使用的设计模式，有时对类(或多个类)结构进行巨大更改。这确实需要在进行过程中更新测试。

让我提出一个不同的解释:对我来说，您至少需要两个级别的测试:

• 单元测试，用于方法测试。这些测试在重构生产代码时会发生变化，以跟随代码修改(它们甚至可以在变化之前完成，以使用 TDD 驱动它)

• 验收测试(可能使用像 FITnesse 或 JBehave 这样的集成测试框架，如果没有，则使用纯 JUnit)- 这些测试是验收的高级标准，它们在重构期间应该不改变，并且在重构结束时仍然通过。事实上，它们是您的工具，是您成功重构的证明。破解代码，不假思索地修改它，在一天结束时，您的验收测试应该仍然通过。如果他们这样做，你就可以走了。如果不是，则表示您损坏了某些东西(或者您的测试一开始就错了)。

(还需要另一个级别的测试:系统测试或集成测试，但它们超出了这个问题的范围)