我加入了一个开发产品的团队。该产品已经存在了大约 5 年左右，并且使用 ASP.NET WebForms。随着时间的推移，它的原始架构已经褪色，整个解决方案中的东西变得相对杂乱无章。这绝不是可怕的，但绝对可以使用一些工作；你们都知道我的意思。
自从大约 6 个月前加入项目团队以来，我一直在执行一些重构。其中一些重构很简单，Extract Method、Pull Method Up 等。一些重构更具结构性。后面的变化让我很紧张，因为没有一套全面的单元测试来伴随每个组件。
整个团队都支持通过重构进行结构更改的需要，但我们的项目经理表达了一些担忧，即我们没有足够的测试来进行重构，并确信我们不会将回归错误引入系统。他希望我们首先编写更多测试（针对现有架构），然后执行重构。我的论点是系统的类结构耦合太紧密，无法编写足够的测试，并且在我们执行重构时使用更多的测试驱动方法可能会更好。我的意思不是针对现有组件编写测试，而是针对特定功能需求编写测试，然后重构现有代码以满足这些需求。
有没有人对最佳行动方案有任何经验？我有自己的想法，但想听听社区的一些意见。
您的 PM 的担忧是有道理的——确保在进行任何重大重构之前对您的系统进行测试。
我强烈建议获取一份 Michael Feather 的《有效地使用遗留代码》一书的副本（“遗留代码”羽毛是指任何未被单元测试充分覆盖的系统）。这充满了关于如何以安全的方式分解你所说的那些耦合和依赖关系的好主意，不会有引入回归错误的风险。
重构程序祝你好运；以我的经验，这是一个令人愉快和宣泄的过程，你可以从中学到很多东西。
您可以并行重新考虑吗？我的意思是使用 TDD 重新编写要重构的部分，但保留现有的代码库。然后在您的新测试满足您的 PM 需求时逐步淘汰现有代码？
我还想提出一个访问Martin Fowler的重构网站的建议。他从字面上写了这本书。
至于将单元测试引入等式，我发现最好的方法是找到一个顶级组件并识别它对具体对象的所有外部依赖关系，并用接口替换它们。完成后，针对您的代码库编写单元测试会容易得多，并且您可以一次完成一个组件。更好的是，您不必丢弃任何单元测试。
对 ASP.Net 进行单元测试可能会很棘手，但是有很多框架可以让它更容易完成。ASP.Net MVC和WCSF等等。
只是抛出了第二条关于有效使用遗留代码的建议，这本书真的让我大开眼界，几乎所有旧的/蹩脚的/不可测试的代码都可以被争论！
Totally agree with the answer from Ian Nelson. Additionally I would start to get some "high level" tests (functional or component tests) in place to preserve the behaviour from the view point of the user. This point might be the most important concern for your PM.