在没有单元测试的情况下,如何优雅地集成单元测试?[已关闭]

技术方法在Michael Feathers的书中有很好的定义 Working Effectively With Legacy Code 由于你不能一次测试整个代码块,你可以沿着想象中的非架构“接缝”将其分开。这些可能是代码中的逻辑瓶颈,其中一个功能块似乎与代码库的其余部分有所隔离。这不一定是拆分它的“最佳”架构位置,而是选择一个可以自己测试的独立逻辑块。此时将其分为两个模块:大部分代码和独立的函数。现在,在这一点上添加自动测试,以执行隔离的功能。这将证明您对逻辑所做的任何更改都不会对大部分代码产生不利影响。

Martin Fowler's Refactoring 这本书是这里很好的参考书。在重构时,将单元测试添加到新重构的类和方法中。试着保持“在你所画的分割线之后”;这将有助于防止兼容性问题。

您需要向他们展示一个计划,以获得重构的代码库。这将包括方法、涉及的步骤、您看到的大块工作以及估计的时间线。在这里提出替代方案也很好:完全重写会更好吗?你应该换语言吗?您是否应该将其转移到面向服务的体系结构?你是否应该将其移入云端,并将其作为托管服务进行销售?所有这些都是他们应该在高层考虑的问题,即使他们今天没有考虑这些问题。

我亲自为这棵树剥皮已经11年了,我只能向你们保证,这是难以置信的不容易。这需要在组织的技术阶梯顶端进行彻底的变革:首席信息官、首席技术官、开发高级副总裁,或者其他任何人。你还必须说服你的技术同行:你可能有一些人对旧产品有着悠久的历史,他们真的不想改变它。他们甚至可能认为你对当前状态的抱怨是对他们编码技能的人身攻击,并可能会蓄意破坏或破坏你的努力。

我真诚地祝你事业顺利!