重构现有系统的可测试性

Question

我加入了一个开发产品的团队。该产品已经存在了大约 5 年，并且使用 ASP.NET WebForms。随着时间的推移，它的原始架构已经褪色，整个解决方案变得相对混乱。这绝不是可怕的，但绝对需要一些工作；你们都知道我的意思。

自从大约 6 个月前加入项目团队以来，我一直在进行一些重构。其中一些重构很简单，例如 Extract Method、Pull Method Up 等。一些重构更具结构性。后面的变化让我感到紧张，因为没有一套全面的单元测试来伴随每个组件。

整个团队都同意通过重构进行结构性改变的需要，但我们的项目经理表达了一些担忧，即我们没有足够的测试来进行重构，并确信我们不会将回归错误引入系统。他希望我们首先编写更多测试（针对现有架构），然后进行重构。我的观点是，系统的类结构耦合得太紧密，无法编写足够的测试，并且在执行重构时使用更多测试驱动的方法可能会更好。我的意思不是针对现有组件编写测试，而是针对特定功能需求编写测试，然后重构现有代码以满足这些需求。这将使我们能够编写在系统中可能具有更长寿命的测试，而不是编写一堆“扔掉”的测试。

有谁有关于最好的行动方案是什么的经验？我有自己的想法，但想听听社区的一些意见。

Answer 1

您的产品经理的担忧是有道理的 - 确保在进行任何重大重构之前对您的系统进行测试。

我强烈建议您买一本迈克尔·费瑟的书 有效地处理遗留代码 （“遗留代码”羽毛是指单元测试未充分覆盖的任何系统）。这充满了关于如何以安全的方式分解您所说的耦合和依赖关系的好主意，而不会带来引入回归错误的风险。

祝重构计划好运；根据我的经验，这是一个令人愉快且宣泄的过程，您可以从中学到很多东西。

Answer 2

你能并行重构吗？我的意思是使用 TDD 重新编写您想要重构的部分，但保留现有的代码库。然后当您的新测试满足 PM 的需求时逐步淘汰现有代码？

Answer 3

我还想提出一个参观的建议 重构 马丁·福勒的网站。他确实写了一本关于这些东西的书。

就将单元测试引入方程式而言，我发现的最佳方法是找到一个顶级组件并识别它对具体对象的所有外部依赖项，并用接口替换它们。完成此操作后，根据代码库编写单元测试就会容易得多，并且一次可以针对一个组件进行测试。更好的是，您不必放弃任何单元测试。

对 ASP.Net 进行单元测试可能很棘手，但有很多框架可以使其变得更容易。 ASP.Net MVC, ， 和 世界科学基金会 仅举几例。

Answer 4

只是抛出第二个建议《有效地处理遗留代码》，这是一本优秀的书，它真正让我大开眼界，几乎所有旧的/蹩脚的/不可测试的代码都可以被争论！

Answer 5

完全同意楼上的回答 伊恩·尼尔森. 。此外，我将开始进行一些“高级”测试（功能或组件测试），以从用户的角度保留行为。这一点可能是您的 PM 最关心的问题。