覆盖率高不等于质量高：行覆盖仅表明代码被执行，未验证逻辑分支；分支覆盖需显式启用，对权限校验等关键逻辑更可靠；mock易致假覆盖；设阈值须结合风险、排除生成代码与胶水层。
覆盖率数字高 ≠ 代码质量高
100% 的 coverage.py 报告只是说明每行代码都被执行过，不说明逻辑分支被充分验证。比如一个 if x > 0: 分支下只测了 x = 5，没测 x = -2 或 x = 0，覆盖率照样可能显示“已覆盖”，但边界条件完全漏掉。
常见错误现象：Coverage: 98% 的项目上线后在 x == 0 场景崩溃；或者 mock 掉所有外部依赖后覆盖率飙升，但真实交互路径压根没跑过。
- 覆盖率是探测器，不是质量证明 —— 它告诉你“哪里没跑”，不告诉你“跑得对不对”
- 函数体里有
try/except，但测试只走try分支，except块虽被“执行”（因语法解析算进行数），实际逻辑未验证 -
coverage.py默认统计的是“语句覆盖”（line coverage），对条件覆盖（branch coverage）需显式开启--branch参数
什么时候该看分支覆盖率而不是行覆盖率
涉及判断逻辑密集的模块，比如权限校验、状态机流转、数值边界处理 —— 这些地方单看行覆盖会严重失真。例如一个 get_user_role(user_id) 函数内有嵌套 if-elif-else 和多个 and/or 组合，行覆盖可能 100%，但实际只触发了其中一条路径。
使用场景：金融计算、风控规则、协议解析等不允许逻辑遗漏的领域。
立即学习“Python免费学习笔记（深入）”；
- 启用分支覆盖：
coverage run --branch -m pytest - 注意
coverage.py对短路表达式（如a and b）的分支识别有限制：它只标记整个表达式是否被完整求值，不拆解子表达式 - 某些 Python 版本（如 3.12+）对 match-case 的分支识别更准确，旧版本可能将整个
case块计为一行，掩盖内部逻辑缺口
mock 导致的覆盖率假象怎么识别
用 patch 或 unittest.mock 替换 I/O、网络、数据库调用后，原本需要等待或失败的路径被绕过，导致大量“空转”代码被计入覆盖，但这些路径在真实环境根本不会按预期执行。
典型表现：测试跑得飞快、覆盖率暴涨、CI 通过，但集成测试或预发环境频繁报错。
- 检查
coverage报告中高频被覆盖但业务逻辑稀疏的模块（如全是return mock_data的 service 层） - 对比
coverage run -m pytest和coverage run --source=app -m pytest的差异 —— 后者限制只统计源码目录，能过滤掉 mock 工具链本身的干扰 - 避免在测试中对同一对象重复
patch：多次 patch 可能导致底层函数实际未执行，却因装饰器机制被误标为“已覆盖”
团队设覆盖率阈值前必须确认的三件事
硬性卡 80% 或 90% 是最省事的做法，也是最容易引发应付式测试的诱因 —— 比如往每个函数末尾加一行 assert True，或对异常分支塞个 try: ... except: pass 再测一次。
真正有用的阈值，得和代码变更风险挂钩。
- 确认 CI 中是否排除了生成代码（如
proto编译产出、SQLAlchemy models 的__table_args__等）—— 这些代码不该由单元测试负责 - 区分核心模块（如支付结算）和胶水层（如日志包装器）：前者建议开分支覆盖 + 行覆盖双指标，后者只需保证调用链通顺即可
- 检查
.coveragerc是否误 exclude 了关键目录（常见坑：exclude = tests/顺手写成exclude = test/，结果整个测试文件夹被忽略，覆盖率虚高）
覆盖率工具本身不理解业务意图。你给它一行 if user.is_premium():，它只管这行有没有执行；至于 is_premium() 返回 True 时扣款逻辑是否正确，它连问都不会问。
