asp.net – 在现有系统上重构可测试性

发布时间：2020-12-16 07:13:38 所属栏目：asp.Net 来源：网络整理

导读：我加入了一个专注于产品的团队.该产品已存在约5年左右,并使用ASP.NET WebForms.它的原始架构随着时间的推移逐渐消失,整个解决方案中的事情变得相对混乱.这绝不是可怕的,但绝对可以使用一些工作;你们都知道我的意思. 自从大约6个月前进入项目团队以来,我一直

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

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

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

有没有人对最佳行动方案有什么经验？我有自己的想法,但希望听到社区的一些意见.

解决方法

您的PM的顾虑是有效的 – 确保在进行任何重大重构之前让您的系统受到测试.

我强烈建议您获取Michael Feather的书籍Working Effectively With Legacy Code的副本(“Legacy Code”Feathers表示任何单元测试未充分涵盖的系统).对于如何以安全的方式分解那些耦合和依赖关系,这是一个很好的想法,不会冒引入回归错误的风险.

好运的重构计划;根据我的经验,这是一个愉快和宣泄的过程,你可以从中学到很多东西.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!