Flask企业级测试覆盖率需显式指定--source和--branch参数，确保动态加载的蓝图、模型及异常分支被统计；必须设TESTING=True、注册所有蓝图、避免提前import，并为每个if/except构造独立测试用例。
Flask 企业级应用的单元测试覆盖率不是靠 pytest 跑完就完事——关键在「测得准」和「不漏路径」。真实项目里，coverage 报 95% 可能只是主干逻辑被扫到了，而 if not current_user.is_authenticated: 这种分支、异常处理、蓝图未注册时的 404、配置切换导致的路由失效，全都不在默认统计范围内。
怎么让 coverage 真实反映业务逻辑覆盖情况
默认 coverage run -m pytest 只统计当前工作目录下导入并执行的代码，但 Flask 企业级项目普遍用应用工厂（create_app()）+ 蓝图动态注册，模型和视图往往在测试运行时才 import。结果就是：models.py 里写了 20 个字段验证，但 coverage report 显示这文件是 0%。
- 必须显式指定
--source=app（或你实际的包名），否则 coverage 不知道该盯哪些模块 - 加
--branch参数，否则if/else、try/except的 else 分支、except 块全算“已覆盖”，实际根本没跑过 - 避免在
conftest.py或 fixture 里提前 import 视图模块——它们应该由测试用例触发时才加载，这样才能让 coverage 捕获到“这个 view 函数到底有没有被调用” - 如果用了
flask-migrate，别把migrations/目录放进--source，它不是业务逻辑，纯生成代码
为什么 test_client() 请求后 coverage 还是漏掉视图函数
常见现象：写了 client.get("/api/users")，响应状态码也对，但对应视图函数在 coverage 报告里显示为未执行。根本原因是——请求没真正进到视图层，卡在了前置钩子或扩展初始化阶段。
- 检查是否漏了
app.config["TESTING"] = True：很多扩展（如 Flask-Login、Flask-SQLAlchemy）依赖这个开关来跳过生产环境逻辑，否则可能直接 raise 异常退出，视图根本不会执行 - 确认所有蓝图已在
create_app()中注册：coverage 统计的是“被 Python 解释器执行过的行”，如果app.register_blueprint(user_bp)没执行，那user_bp里所有代码都不会被 import，自然不计入统计 - 避免在视图函数里做耗时操作（如外部 API 调用、大文件读取）：测试超时或抛错会导致 coverage 中断记录，看起来像“没覆盖”，其实是中途崩了
- 用
print()或logging.debug()在视图开头打点，确认它确实被执行了——别只信 status_code
如何识别那些“看似覆盖实则危险”的高危未覆盖分支
coverage 报告里最骗人的不是红色（未执行），而是黄色（部分分支）。比如一个用户创建接口：
SkillSub Pro - Python 题解与代码注释双功能技能功能概述SkillSub Pro - Python 题解与代码注释双功能技能是一项面向实际任务的技能，主要用于SkillSub Pro 是一个 Python 题解生成与代码注释的 双功能合体技能 ，专为学生、算法学习者和开发者设计；✅ 一个技能，两种用途 ：；核心要点📝 题解模式 ：输入题目/题号，自动生成完整 Python 题解（含详细注释、解题思路、复杂度分析）；💬 注释模式 ：输入 Python 代码，自动添加详细中。它将相关步骤、
立即学习“Python免费学习笔记（深入）”；
def create_user():
data = request.get_json()
if not data:
return {"error": "no data"}, 400
user = User(**data)
try:
db.session.add(user)
db.session.commit()
return {"id": user.id}, 201
except IntegrityError:
db.session.rollback()
return {"error": "duplicate"}, 409
这个函数即使所有测试都 pass，IntegrityError 分支也可能永远不触发——因为你测试用的都是干净数据。这类分支必须显式构造冲突数据去覆盖：
- 在测试里插入同 username 用户，再 POST 相同 username，强制走
except分支 - 用
monkeypatch模拟db.session.commit()抛出IntegrityError，验证错误处理路径 - 对每个
if条件写独立测试用例，而不是塞在一个 test 函数里用多个 assert —— 否则只要第一个 assert 失败，后面分支根本不会执行 - 特别注意
g、session、request.args等上下文对象的空值/非法值场景，它们极易产生隐藏分支
真正难的不是凑数字，是让每个 if、每个 except、每个配置开关切换后的行为，都有对应测试用例推着它跑一遍。coverage 工具只告诉你“哪行没跑”，但决定“哪行必须跑”的，是你对业务边界和失败模式的理解。
