必须显式覆盖 case _ 分支，否则测试会漏掉静默 fallback 行为；需用 pytest.mark.parametrize 构造边界输入（如空容器、none、意外类型）并显式声明输入对应 case，守卫条件须单独验证真假分支，断言应聚焦输出或副作用而非绑定变量。
必须显式覆盖 case _ 分支，否则测试会漏掉静默 fallback 行为——这是 match-case 单元测试最容易忽略的致命点。
为什么不能只测“能走通的路径”
Python 的 match 不强制穷尽匹配，未被任何 case 捕获的输入会直接跳过或落入 case _。如果测试只构造 happy-path 输入（比如只传 200、404），就完全无法验证默认分支是否按预期兜底。
- 实际业务中，
case _常用于日志记录、降级返回或异常上报，漏测等于放行潜在故障 - pytest 运行时不会警告“有未覆盖的分支”，不像 Rust 编译器会报错
- mock 对象若结构不匹配（例如传入
dict却期待Point实例），也会无声落入case _，而非抛出异常
如何用 pytest.mark.parametrize 覆盖所有输入类型
别只列几个数字或字符串，要按模式类型边界构造输入：常量、空容器、None、意外类型、嵌套结构。
- 对
case [x, y]:，必须测[]、[1]、[1, 2, 3]、"hello"、None - 对
case Point(x, y) if x == y:，要分别测Point(1, 1)（守卫为真）、Point(1, 2)（结构匹配但守卫为假）、(1, 2)（类型不匹配） - 用
@pytest.mark.parametrize("input_val,expected_case", [...])显式声明“这个输入应进入第几个 case”，而不是只断言返回值
测试带守卫条件（if）的 case 时的关键陷阱
守卫表达式在结构匹配成功后才求值，且短路逻辑和副作用会让测试行为不可预测。
- 守卫里调用的函数（如
if is_valid(x)）必须可 patch，否则 I/O 或状态变更会污染测试 - 单独写一个测试用例，输入满足结构但守卫为
False，确认它没进该分支（比如落到下一个case或case _） - 避免在守卫里写
if log_and_return_true(x)这类有副作用的表达式；若已存在，测试前必须重置日志缓冲区或 mock 返回值
嵌套 match 或变量绑定场景下的断言误区
case [x, y]: 中的 x、y 是绑定变量，仅在该 case 块内有效——你不能在测试里 assert x == 1。
- 断言目标只能是函数整体输出、外部状态变更（如写入文件、修改全局字典）、或 mock 调用次数
- 嵌套
match共享同名变量（如外层case Node(left, right):，内层又match left:），测试数据必须确保left和right结构清晰无歧义 - 若 match 在
try块中，要测异常触发时是否正确跳过所有 case（Python 3.10 中，异常不会被 match 捕获，仍向上抛）
最常被跳过的其实是 case _ 的边界输入——比如传入 float('nan')、自定义类实例、或 Enum 成员，这些看似“奇怪”的值，恰恰最容易触发默认分支。测试不是为了证明代码能跑，而是为了证明它在意外输入下不崩、不误判、不静默失败。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
