单元测试覆盖率推进策略
“没时间写测试” → 线上频繁出问题 → 更没时间写测试。如何打破这个恶性循环?
一、为什么单元测试覆盖率低
- 1.1 历史债务——老代码没有测试
- 1.2 赶进度——测试被忽视
- 1.3 写测试难——依赖太多无法 Mock
二、覆盖率目标设定
- 2.1 不要追求 100%——80% 是合理的上限
- 2.2 核心链路优先——支付、下单等高价值链路
- 2.3 工具类优先——纯函数容易测试
三、增量策略
- 3.1 新增代码——覆盖率不低于 80%(CI 卡点)
- 3.2 修改代码——补充修改部分的测试
- 3.3 存量代码——按优先级逐步补充
- 3.4 JaCoCo 覆盖率报告集成
四、让测试更好写
- 4.1 Mockito——Mock 外部依赖
- 4.2
@SpringBootTest——集成测试 - 4.3 Testcontainers——真实 MySQL/Redis 环境
- 4.4 H2 内存数据库——快速 DAO 层测试
五、测试分层
- 5.1 单元测试——Mock 所有依赖,快速
- 5.2 集成测试——真实依赖,覆盖关键链路
- 5.3 E2E 测试——全链路,少量
六、CI 卡点配置
- 6.1 JaCoCo 规则——
class missed < 0.2 - 6.2 只在新增代码上卡覆盖率
- 6.3 覆盖率报告可视化
七、总结
- 覆盖率是手段不是目的——核心链路必须测
- 增量策略 + CI 卡点是推进覆盖率的有效手段
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 谜思录!