ste*_*e_c 5 asp.net refactoring automated-tests
我加入了一个专注于产品的团队.该产品已存在约5年左右,并使用ASP.NET WebForms.它的原始架构随着时间的推移逐渐消失,整个解决方案中的事情变得相对混乱.这绝不是可怕的,但绝对可以使用一些工作; 你们都知道我的意思.
自从大约6个月前进入项目团队以来,我一直在进行一些重构.其中一些重构很简单,Extract Method,Pull Method Up等等.有些重构更具结构性.后者的变化让我感到紧张,因为没有一套全面的单元测试来配合每个组件.
整个团队都需要通过重构来进行结构更改,但是我们的项目经理表达了一些担忧,即我们没有足够的测试来进行重构,并确信我们没有将回归错误引入系统.他希望我们首先编写更多测试(针对现有架构),然后执行重构.我的论点是系统的类结构与编写足够的测试过于紧密耦合,并且在我们执行重构时使用更多的测试驱动方法可能会更好.我的意思是不是针对现有组件编写测试,而是编写针对特定功能需求的测试,然后重构现有代码以满足这些需求.
有没有人对最佳行动方案有什么经验？我有自己的想法,但希望听到社区的一些意见.
您的PM的顾虑是有效的 - 确保在进行任何重大重构之前让您的系统受到测试.
我强烈建议您获取Michael Feather的书"有效使用旧版代码"("Legacy Code"Feathers)的副本,指任何单元测试未充分涵盖的系统.对于如何以安全的方式分解那些耦合和依赖关系,这是一个很好的想法,不会冒引入回归错误的风险.
好运的重构计划; 根据我的经验,这是一个愉快和宣泄的过程,你可以从中学到很多东西.