什么时候要求补测试
有三类情况应当明确要求补测试：行为发生变化却没有对应测试、修复缺陷却没有能复现该缺陷的用例、关键分支（错误路径与边界）完全没有覆盖。反过来，纯注释、纯格式以及没有行为变化的机械重构可以豁免——对它们强行要求测试只会浪费精力。
基本信息
| 要求前提 | 改动改变了可观察行为，或修复了具体缺陷 |
|---|---|
| 范围要求 | 指明缺哪条路径，而不是笼统要求「测试再全点」 |
| 豁免情形 | 纯注释、纯格式、无行为变化的机械重构 |
| 验收标准 | 新增用例在没有修复的版本上必须失败 |
必须要求的情形
- 行为变化没有新测试：要求补，并确认测试在改错时能失败。
- 缺陷修复没有复现用例：先加能复现的测试，再谈合并。
- 关键分支未覆盖：错误路径、边界值、权限拒绝等路径至少各一条。
- 修复的是线上问题：把复现步骤固化成用例，防止回归。
可以豁免的情形
- 纯注释与文档更新：行为未变，测试无法验证新增信息。
- 纯格式化或改名：既有测试已能证明行为不变。
- 无行为变化的机械重构：把重点放在确认行为确实没变。
- 仅调整日志文本但监控未依赖该文本：可作为例外，但要在评论里说明判断依据。
要求方式对比
| 写法 | 效果 |
|---|---|
| 「加一下测试」 | 作者不知从哪下手，可能补无用用例 |
| 「错误分支没有用例，请补一条返回空输入的」 | 目标明确，可立即执行 |
| 「把线上复现步骤写成用例」 | 既防回归，又留下问题记录 |
| 不说明理由直接拒绝 | 作者感受为刁难，讨论容易升级 |
要求补测试时给出范围：只说「加测试」会让作者不知道从哪下手，最后补出一堆无效用例。
验收时把断言改成相反期望跑一遍：如果仍然绿灯，说明这条用例还没有约束力。