3. 覆盖率驱动开发：TDD与覆盖率的关系、覆盖率作为质量门禁、覆盖率目标设定
好，咱们接着聊。前面两章我们把覆盖率的“是什么”和“怎么测”讲清楚了。这一章，我想聊聊一个更实际、也更考验工程能力的话题——怎么用覆盖率来驱动开发。
说白了，就是让覆盖率从“事后统计”变成“事前约束”。我个人习惯把这种做法叫做覆盖率驱动开发（Coverage-Driven Development，CDD）。它不是要取代TDD，而是给TDD加了一把“尺子”。
3.1 TDD与覆盖率的关系
TDD（测试驱动开发）的核心流程大家都知道：红-绿-重构。先写一个会失败的测试，再写刚好能让它通过的代码，最后重构优化。
但这里有个坑——你怎么知道你的测试写得够不够？
我记得有一次，团队里一个小伙子很兴奋地跟我说：“老大，我TDD跑通了，所有测试都绿了！”我一看，代码覆盖率只有23%。嗯，他确实写了测试，但只测了最核心的那条路径，边界条件、异常分支全都没覆盖。
所以我的观点是：TDD保证了你“写了测试”，但覆盖率保证了你“写对了测试”。
它们俩的关系，我画了张图，你看一眼就明白了：
你看，TDD和覆盖率不是二选一，而是互补的闭环。TDD驱动你写测试，覆盖率告诉你测试够不够。不够？那就回去补。补完了再跑一遍覆盖率。直到达标为止。
3.2 覆盖率作为质量门禁
什么叫“质量门禁”？说白了就是一道关卡。代码覆盖率不达标，代码就不允许合并到主分支。
我曾经在一个项目中吃过亏。当时团队赶进度，测试覆盖率只有40%多，大家觉得“先上线再说”。结果上线第三天就出了线上故障——一个异常分支从来没被测试覆盖到，生产环境一触发就崩了。
从那以后，我定了一条铁律：覆盖率不达标，代码不能合入。
具体怎么落地？我建议分三步走：
- 在CI/CD流水线中集成覆盖率检查。每次提交代码，自动跑测试并计算覆盖率。
- 设置硬性阈值。比如行覆盖率不低于80%，分支覆盖率不低于70%。低于这个值，流水线直接失败。
- 生成覆盖率报告。自动生成HTML报告，标注哪些行没覆盖到，方便开发者定位。
这里我贴一个简单的CI配置示例，用的是GitLab CI + pytest-cov：
# .gitlab-ci.yml 片段
test:
stage: test
script:
- pytest --cov=my_project --cov-report=term --cov-report=html --cov-fail-under=80
artifacts:
paths:
- htmlcov/
注意那个 --cov-fail-under=80，意思就是覆盖率低于80%就算失败。嗯，这个参数救过我好几次。
3.3 覆盖率目标设定
说到目标设定，很多团队会犯一个错误——一刀切。所有模块、所有代码都要求同一个覆盖率标准。这其实不合理。
你想想看，核心业务逻辑和工具类函数，重要性能一样吗？肯定不一样。所以我建议分层次设定目标。
下面这张表是我在项目中常用的设定方式：
| 代码层级 | 行覆盖率目标 | 分支覆盖率目标 | 说明 |
|---|---|---|---|
| 核心业务逻辑 | ≥ 90% | ≥ 85% | 支付、订单、用户鉴权等 |
| 通用服务层 | ≥ 80% | ≥ 75% | 数据访问、缓存、消息队列 |
| 工具类/辅助函数 | ≥ 70% | ≥ 60% | 字符串处理、日期格式化等 |
| 配置/模板代码 | ≥ 50% | 不强制 | 框架生成的样板代码 |
这里我想多说一句：覆盖率目标不是一成不变的。项目初期可以低一些，随着迭代逐步提高。我见过一个团队，第一个月目标设60%，第二个月提到70%，第三个月到80%。这样团队有个适应过程，不会一开始就被“吓到”。
另外，还有一个容易被忽略的点——新增代码和存量代码要区别对待。我个人的做法是：
- 新增代码：强制要求覆盖率达标，不达标不能合入。
- 存量代码：逐步提升，每次改到相关文件时顺手补测试。
这样做的好处是，不会因为“历史遗留问题”拖慢新功能的开发节奏。我曾经在一个老项目上试过“全面补测试”，结果花了两个月，业务需求一个都没做。老板差点把我叫去喝茶。
所以，增量优先，存量渐进，这是我踩过坑之后总结出来的经验。
最后总结一下这一章的核心：覆盖率驱动开发，不是让你为了覆盖率而写测试，而是让你用覆盖率这个指标，来指导你写更有质量的测试。TDD给你流程，覆盖率给你标尺，两者结合，才是真正的质量保障。