答案。

自动化测试遗留代码是IT领域中最大的经典问题之一。

问题历史： 很多公司面临测试那些在没有考虑将来自动化的情况下编写的系统的必要性。这些项目通常有薄弱的文档、高技术债务和缺乏独立组件的情况。

问题： 主要的困难源于

• 缺乏测试钩子和集成点
• 无法隔离数据进行测试
• 模块之间的高度相互依赖
• 大量的异常和变更未在代码中反映

解决方案： 通常流程是逐步进行的：

1. 系统分析： 需要确定关键的业务流程并同意自动测试的覆盖范围。
2. 引入测试点： 尽可能将代码的一部分封装为代理，适配测试双胞胎或使用依赖注入模式。
3. 逐步覆盖自动测试： 首先为“最简单”和关联性最少的代码编写测试。
4. 持续支持和重构： 添加测试后，利用它们作为改进的安全网。

关键特色：

• 测试通常不是从零开始写的，而是对现有功能的“包装”。
• 需要逐步将可测试性添加到架构中。
• 业务应尽可能参与关键场景的规范化。

复杂问题。

是否可以在遗留代码完全重构之前开始编写自动测试？

是的，往往自动测试正是为了确保重构的安全性。不能等待完全的“完美”——相反，测试帮助大胆地进行更改。

是否应该立即尝试用自动测试覆盖所有遗留代码？

不。需要集中精力在风险最高和最常用的场景上。随便“覆盖所有”会损害速度且没有意义。

是否必须引入像DI这样的现代模式来测试遗留代码？

不，但如果资源允许，建议使用。第一步——至少部分隔离、模拟和特殊测试点在代码中。

常见错误和反模式

• 一次性迁移所有代码为自动测试——项目停止并失去商业意义。
• “偏执地”覆盖不重要的功能。
• 开发、测试与业务之间缺乏沟通。

生活中的例子

消极案例

团队试图通过将所有旧应用程序重写为SOLID模式并覆盖100%的代码来引入自动测试。

优点：

• 基础架构的改善。
• 从长期来看，测试可能会带来益处。

缺点：

• 开发延迟几个月。
• 不断出现的错误与商业需求不同步。
• 当测试完成时，代码已失去时效性。

积极案例

仅为关键计算点逐步引入自动测试，同时引入特别的替代品，尽量不改变整体代码。

优点：

• 项目延迟最低。
• 在改进时增强信心。
• 随着工作的进行，有可能增加覆盖率。

缺点：

• 难以记录非标准的方法。
• 仍然有部分代码未覆盖。