重构以在现有系统上实现可测试性

Question

我加入了一个开发产品的团队。该产品已有5年左右的历史，使用的是ASP.NET WebForms。随着时间的推移，它的原始架构逐渐消失，在整个解决方案中，事情变得相对混乱。这绝不是可怕的，但绝对可以使用一些工作；你们都知道我的意思。

自从6个月前加入项目团队以来，我一直在执行一些重构。其中一些重构是简单的，提取方法，拉出方法等等。一些重构更具结构性。后一种变化让我感到紧张，因为没有一套全面的单元测试来伴随每个组件。

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

有谁有经验知道最好的行动方案是什么？我有自己的想法，但我希望听到一些来自社区的意见。

Answer 1

你的项目经理的担忧是有道理的--在进行任何重大重构之前，请确保你的系统得到了测试。

我强烈建议你买一本Michael Feather的书“Working Effectively With Legacy Code”(“遗留代码”中的“羽毛”指的是单元测试没有充分覆盖的任何系统)。这篇文章充满了关于如何以一种安全的方式分解你所说的那些耦合和依赖关系的好主意，而且不会有引入回归错误的风险。

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

Answer 2

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

Answer 3

我还想提一个建议，让我访问Martin Fowler的Refactoring网站。他确实写了一本关于这些东西的书。

至于在等式中引入单元测试，我发现最好的方法是找到一个顶级组件，识别它对具体对象的所有外部依赖项，并用接口替换它们。一旦你做到了这一点，针对你的代码库编写单元测试就会容易得多，而且你可以一次只做一个组件。更好的是，您不需要丢弃任何单元测试。

单元测试ASP.Net可能很棘手，但是有很多框架可以让它变得更容易。ASP.Net MVC和WCSF等等。