Unit testing 遗留代码中的重构-单元测试-设计三重困境

在处理遗留代码时，如何解决这个问题

• 您处理的类设计得不好，需要进行一些严重的设计更改
• 您处理的类大多是紧密耦合的
• 您没有足够的单元测试来进行重构
• 您不会添加新的单元测试，因为设计很糟糕，您无论如何都要更改它
• 你不能轻易改变设计，因为
  • 紧密耦合，没有足够的单元测试——这些东西可能真的是错误的，因为它需要同时为多个类进行新的设计，而没有任何安全网

---

你从哪里开始？如何解决此问题？

首先要确保不更改代码的行为。 如果您编写的单元测试断言了代码当前的行为方式，那么您可以对代码进行更改，并检查测试是否仍然通过，如果测试通过，那么代码行为没有改变。

---

然后，您可以随意重构代码。当你重构设计时，你也重构测试，但不要改变它们的断言。

一个鸡和蛋的问题

如果由于紧密耦合而无法编写一些像样的单元测试，那么更好的方法可能是从上到下工作

如果您还没有集成、系统和/或GUI测试，这将是在开始创建单元测试之前创建它们的一个很好的理由。一旦你有了它们，你就可以开始重构代码来创建像样的单元测试，并且仍然相当有信心你所有的compassing测试都会发现你最明显的错误

请注意，在我个人看来，这些测试用例应该这样创建，一旦您准备好开始创建单元测试和重构代码，就不必修改它们

关于这一主题的必读读物是迈克尔·费瑟

结论

我概述的策略适用于各种各样的变化， 然而，也有一些警告。有时唯一合适的拐点 可以为一组类找到的点是系统边界。 在某些应用中，系统边界可能相当宽：它 包含GUI、对其他外部库的调用、数据库、， 在这些情况下，获得不变量的最佳方法是开始 写史蒂夫·麦康奈尔称之为“烟雾测试”的东西来对抗其他人 系统

---

Feathers将他的文章扩展成一本优秀的书：