要覆盖match-case所有分支，需为每个case编写独立测试用例，严格匹配其模式；特别注意case _、守卫条件（需True/False两组输入）及边界情况。
pytest怎么测match-case的每个分支都走到了
要让 pytest 覆盖 match 语句的所有 case 分支，关键不是“模拟 match”，而是确保被测函数在不同输入下实际进入不同分支——pytest 本身不感知语法结构，只看运行时执行路径。coverage.py（pytest-cov）能识别这些分支，但前提是每条 case 确实被执行。
常见错误是只传一个值、漏掉 _ 或守卫条件（if）分支，导致 coverage 显示 “partial branch” 或红色未覆盖块。
- 对每个
case写一个独立的测试用例，输入严格对应该分支的匹配模式（如字面量、类实例、结构化解包） - 显式测试
case _:分支，用一个完全不匹配的输入（比如给匹配int的 match 传"abc"） - 含守卫的
case x if x > 10:，必须提供满足和不满足条件的两组输入，否则守卫逻辑本身不会被完整覆盖 - 如果 match 对象是自定义类，确认该类实现了
__match_args__或使用关键字匹配，否则可能意外落入_
match-case里抛异常或return会影响测试断言吗
会，而且影响很直接：一旦某个 case 执行了 return 或引发未捕获异常，函数就提前退出，后续分支根本不会执行——这本身是正确行为，但测试时容易误判为“没覆盖”。重点在于验证「输出结果」和「异常类型」是否符合预期，而不是看函数有没有跑到底。
- 用
pytest.raises(ValueError)明确断言某输入触发了case ...: raise ValueError() - 对有
return的分支，直接检查函数返回值，例如assert parse_status("done") == "completed" - 避免在测试里用
try/except包裹整个调用再去判断，这样会掩盖真实控制流，也增加断言复杂度 - 注意：如果 match 前有预处理逻辑（比如先
str(x)），异常可能发生在 match 外部，此时 coverage 会显示 match 块整体未执行——得先 fix 预处理再测 match
带类型提示的match-case在pytest里需要额外mock吗
不需要。Python 的类型提示（包括 match 中的 case Point(x, y):）在运行时不生效，pytest 测试的是实际对象结构，不是类型注解。mock 的目标应是外部依赖，不是类型系统。
立即学习“Python免费学习笔记（深入）”；
- 测试结构匹配时，直接构造符合模式的对象即可，例如
match期待Point实例，就传Point(1, 2)，别 mockPoint类本身 - 如果
Point构造开销大或有副作用，才考虑用unittest.mock.Mock替换其实例，但必须确保它支持属性访问（mock.x,mock.y）或实现__match_args__ - 类型检查工具（如 mypy）和测试是两回事：mypy 报错不影响 pytest 运行，pytest 覆盖率高也不代表 mypy 无报错
- 用
typing.TypeGuard做守卫时，pytest 只关心其返回值布尔结果，无需 mock 类型检查逻辑
为什么coverage显示match块只有50%覆盖率
大概率是守卫条件（if 子句）只测了一边，或者 _ 分支没触发。coverage.py 把每个 case 的头部和守卫表达式都当作独立分支点，缺一不可。
例如这个代码：
match data:
case int(x) if x > 0:
return "positive"
case int(x) if x < 0:
return "negative"
case _:
return "other"
它实际有 4 个分支点：两个 if 各占 2 个（True/False），加上 _ 入口。只测 5、-3、"abc" 仍可能漏掉某个 if 的 False 路径（比如传 0 才能让第一个 if x > 0 为 False 并继续尝试下一个 case）。
- 运行
pytest --cov=myapp --cov-report=term-missing查看具体哪行标红，定位到是哪个if或_缺失 - 对守卫条件，必须提供使条件为 True 和 False 的输入；对多个守卫并列的 case，注意它们是顺序匹配，False 不会跳到下一个 case，除非当前 case 模式本身不匹配
- 如果用了
case [x, y]这类序列模式，记得测长度不足（如[]或[1]）的情况，它们通常落入_
