测试检查看什么
Google 评审指南把测试单独列为一档关注点：新增或改变的行为是否有测试覆盖、测试是否真的能失败、断言是否具体到能定位问题、修复缺陷时是否留下了能复现该缺陷的用例。测试是改动唯一的回归防线，评审时对它放水，等于把风险留给下一次上线。
基本信息
| 关注范围 | 新增行为的覆盖、断言有效性、回归保护 |
|---|---|
| 有效性验证 | 把断言改成相反期望，确认测试会变红 |
| 回归保护 | 复现缺陷的用例纳入测试集并持续运行 |
| 豁免情形 | 纯注释、纯格式、无行为变化的机械结构调整 |
逐项检查什么
- 新增或修改的行为，关键路径是否有测试覆盖（含错误与边界分支）。
- 测试真的能失败吗：断言是否具体，避免只断言「没有抛异常」。
- 修缺陷是否先有能复现的用例：先红后绿才说明修复到位。
- 用例名是否表达场景与期望，让失败信息本身就说明问题。
- 是否动了既有断言：被放宽的断言往往掩盖了行为变化。
无效测试的典型形态
| 形态 | 为什么无效 |
|---|---|
| 只断言不抛异常 | 任何实现都通过，无法发现错误 |
| 断言与实现同源 | 复用了同一处误解，改错也一起改对 |
| 覆盖率凑数 | 永远不会失败的测试等于没有测试 |
| 大量 mock 断言调用顺序 | 测的是调用细节，重构即碎 |
验证测试有效性
验证测试有效性
# 把断言期望改成错的值，确认测试变红
# 再改回来：若两条都绿，说明断言没有约束力
# 检查是否覆盖错误路径：只测成功分支不算完整
# 修缺陷的用例：先在没有修复的版本上跑一遍，必须是红的要求补测试怎么说
- 指明缺哪条路径：「错误分支没有用例」，而不是笼统要求「测试再全点」。
- 说明为什么现在要补：该路径已经在线上出过问题，或改动直接改到它。
- 给出可接受的最小范围：一条能失败的用例，好过十条无断言用例。
- 机械重构不必强行要求新测试：既有测试已能验证行为不变。
Google 评审指南把测试单列一档：正确且有用的测试是评审重点，而不是附带项。
改动行为却只改实现不改测试，是测试类问题里最常见的隐患：旧断言被悄悄放宽，回归防线随之失效。