重构现有系统的可测试性 [英] Refactoring for Testability on an existing system

问题描述

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

I've joined a team that works on a product. This product has been around for ~5 years or so, and uses ASP.NET WebForms. Its original architecture has faded over time, and things have become relatively disorganized throughout the solution. It's by no means terrible, but definitely can use some work; you all know what I mean.

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

I've been performing some refactorings since coming on to the project team about 6 months ago. Some of those refactorings are simple, Extract Method, Pull Method Up, etc. Some of the refactorings are more structural. The latter changes make me nervous as there isn't a comprehensive suite of unit tests to accompany every component.

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

The whole team is on board for the need to make structural changes through refactoring, but our Project Manager has expressed some concerns that we don't have adequate tests to make refactorings with the confidence that we aren't introducing regression bugs into the system. He would like us to write more tests first (against the existing architecture), then perform the refactorings. My argument is that the system's class structure is too tightly coupled to write adequate tests, and that using a more Test Driven approach while we perform our refactorings may be better. What I mean by this is not writing tests against the existing components, but writing tests for specific functional requirements, then refactoring existing code to meet those requirements. This will allow us to write tests that will probably have more longevity in the system, rather than writing a bunch of 'throw away' tests.

有没有人知道什么是最好的行动方案?我有自己的想法，但想听听社区的一些意见.

Does anyone have any experience as to what the best course of action is? I have my own thoughts, but would like to hear some input from the community.

推荐答案

您的 PM 的担忧是正确的 - 在进行任何重大重构之前，请确保您的系统处于测试状态.

Your PM's concerns are valid - make sure you get your system under test before making any major refactorings.

我强烈建议购买 Michael Feather 的书Working有效地使用遗留代码(遗留代码"羽毛是指任何未被单元测试充分覆盖的系统).这充满了关于如何以安全的方式分解您所说的那些耦合和依赖关系的好主意，不会有引入回归错误的风险.

I would strongly recommend getting a copy of Michael Feather's book Working Effectively With Legacy Code (by "Legacy Code" Feathers means any system that isn't adequately covered by unit tests). This is chock full of good ideas for how to break down those couplings and dependencies you speak of, in a safe manner that won't risk introducing regression bugs.

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

Good luck with the refactoring programme; in my experience it's an enjoyable and cathartic process from which you can learn a lot.

这篇关于重构现有系统的可测试性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！