Refactoring for Testability on an existing system我已经加入了一个致力于产品的团队。该产品已经存在约5年了，并且使用ASP.NET WebForms。随着时间的流逝，其原始体系结构逐渐消失，整个解决方案中的事物变得相对混乱。这绝不可怕，但是绝对可以使用一些工作。你们都知道我的意思。 自大约6个月前加入项目团队以来，我一直在进行一些重构。其中一些重构很简单，例如"提取方法"，"拉出方法"等。某些重构更具结构性。后面的更改使我感到紧张，因为没有一个全面的单元测试套件可以伴随每个组件。 整个团队都需要通过重构进行结构更改，但是我们的项目经理表达了一些担忧，即我们没有足够的测试来进行重构，并且确信我们不会在系统中引入回归错误。他希望我们首先(针对现有架构)编写更多测试，然后执行重构。我的观点是，系统的类结构过于紧密，无法编写足够的测试，并且在执行重构时使用更多的"测试驱动"方法可能会更好。我的意思是不是针对现有组件编写测试，而是针对特定功能要求编写测试，然后重构现有代码以满足这些要求。这将使我们能够编写可能在系统中具有更长寿命的测试，而不是编写一堆"扔掉"的测试。 有人对最佳的行动方法有什么经验吗？我有自己的想法，但想听听社区的意见。 PM的担忧是正确的-在进行任何重大重构之前，请确保对系统进行测试。 我强烈建议您获得一份迈克尔·费瑟(Michael Feather)的著作，《有效地使用遗留代码》("遗留代码"指的是任何单元测试未充分涵盖的系统)。对于如何以安全的方式分解您所说的那些耦合和依赖性，这充满了好主意，而不会冒引入回归错误的风险。 重构计划祝您好运；以我的经验，这是一个令人愉快的宣泄过程，您可以从中学到很多东西。 您可以并行重构吗？我的意思是用TDD重新编写要重构的部分，但保留现有的代码库。然后，当新测试满足PM需求时，逐步淘汰现有代码？ 我也想提出一个建议，以访问Martin Fowler的Refactoring网站。他从字面上写了这本书。 就将单元测试引入方程式而言，我发现的最佳方法是找到一个顶层组件，并确定它对具体对象的所有外部依赖关系，然后将它们替换为接口。完成此操作后，针对您的代码库编写单元测试将变得容易得多，并且您一次只能将其做为一个组件。更好的是，您将不必丢弃任何单元测试。 单元测试ASP.Net可能很棘手，但是有很多框架使其更容易实现。 ASP.Net MVC和WCSF等。 完全同意Ian Nelson的回答。另外，我将开始进行一些"高级"测试(功能或组件测试)，以从用户的角度保留行为。对于您的PM，这可能是最重要的问题。 只是提出第二条建议"有效地使用旧版代码"，这是一本非常出色的书，确实使我大开眼界，几乎可以解决所有旧的/糟糕的/不可测试的代码！ |
