单元测试覆盖率的迷思

很多团队把「单元测试覆盖率 100%」当成追求的目标，仿佛覆盖率数字上去了，质量就有保障了。但实践中我们会发现，覆盖率是一个很容易被「玩坏」的指标——它衡量的是代码被执行过，而不是代码被验证过。

覆盖率不等于质量

一行断言都没有的测试，只要调用到了目标函数，同样能贡献覆盖率。一个常见的反例：为了完成覆盖率指标，测试里写了一堆「只执行、不校验」的用例，跑完覆盖率报表很漂亮，但回归时什么问题都拦不住。这样的测试甚至是有害的——它给团队一种「有测试兜底」的错觉，反而在重构时放大了风险。

真正该关注的三件事

第一，断言质量。每个测试用例都应该有明确的断言：给定输入，期望输出是什么，边界在哪里。没有断言的测试只是「执行了代码」，不是「验证了行为」。

第二，行为覆盖而非行覆盖。分支覆盖、条件覆盖比单纯的语句覆盖更能反映测试的有效性。一个 if 分支只走了一遍 true 路径，行覆盖是 100%，分支覆盖却只有 50%——而 bug 往往藏在没走过的那条路径里。

第三，变更敏感度。好的测试套件应该在代码被改坏时变红。如果对测试做个「变异测试」——故意在代码里植入几个小错误——而测试套件依然全绿，说明这些测试的断言太弱了。

实践建议

覆盖率适合作为「发现盲区」的仪表盘，而不是 KPI。比较务实的做法是：把覆盖率当作预警线（比如新代码低于 60% 就提醒），而不是追求全局 100%；对核心业务逻辑要求分支覆盖，对工具类、配置类代码放宽；在代码审查里关注「测试是否真的在验证行为」，而不是「测试写够了没有」。

另外一个容易被忽略的点：测试的可维护性和覆盖率同样重要。一个写满了具体返回值、断言粒度细到实现细节的测试，会让每次重构都变成灾难——改一行实现要改十个测试。这类「脆弱测试」会慢慢消耗团队的耐心，最后被整体放弃。好的单元测试应该验证「契约」而不是「实现」，输入输出定住，内部怎么变都不用动。

总结一下：覆盖率是手段，不是目的。它回答的是「哪些代码没被测到」，但回答不了「测得够不够好」。与其盯着数字，不如盯着断言质量和行为覆盖，让测试真正成为重构的底气。