异常测试需验证类型、条件与上下文三者匹配；assertRaises须用上下文管理器或传函数引用（勿带括号调用）；assertRaisesRegex支持消息正则匹配；多异常分支应分方法独立覆盖；自定义异常须正确导入类名。
能验证异常是否被正确抛出，就说明异常触发逻辑基本可靠；但只验证“有没有异常”远远不够，必须同时确认异常类型、触发条件和上下文是否精准匹配业务预期。
assertRaises 要么用上下文管理器，要么传函数引用，别直接调用
常见错误是把待测函数带括号执行，导致异常在 assertRaises 捕获前就炸了，测试直接中断：
self.assertRaises(ValueError, parse_int('N/A')) # ❌ 错！这里已经抛出异常了正确写法有两种：
- 作为上下文管理器（推荐）：用
with self.assertRaises(ValueError):包裹调用语句，清晰、安全、支持后续断言 - 传函数名 + 参数：写成
self.assertRaises(ValueError, parse_int, 'N/A')，注意是parse_int（无括号），不是parse_int('N/A')
上下文方式还能继续检查异常对象本身，比如 e.args[0] 或自定义属性，而函数引用方式做不到这点。
立即学习“Python免费学习笔记（深入）”；
assertRaisesRegex 比 assertRaises 更实用，尤其对 ValueError 类异常
很多函数（如 int()、json.loads()）抛出的 ValueError 只靠类型无法区分语义。比如 int('abc') 和 int(' ') 都抛 ValueError，但错误信息不同。
这时用 assertRaisesRegex 可以同时验证类型和消息模式：
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
self.assertRaisesRegex(ValueError, r'invalid literal.*base 10', int, 'xyz')
注意正则要加 r'' 原始字符串，避免转义干扰；错误消息可能因 Python 版本略有差异，建议用模糊匹配（如 'invalid literal' 而非完整消息）。
测试多个异常分支时，每个分支必须独立覆盖，不能合并断言
一个函数可能在不同条件下抛不同异常（比如参数为空抛 ValueError，类型错误抛 TypeError），容易犯的错是只测一种情况，或用同一个测试方法覆盖多个路径。
正确做法是为每种异常路径写单独测试方法：
-
test_divide_by_zero→ 专测ZeroDivisionError -
test_negative_timeout→ 专测ValueError（含消息校验） -
test_non_numeric_input→ 专测TypeError
这样失败时能立刻定位是哪个分支没处理好，而不是在一堆 if 判断里手动排查。
自定义异常必须显式 import 并在测试中完整引用类名
如果项目定义了类似 class ValidationError(Exception): 的异常，测试里必须确保导入路径一致。常见坑是：
- 在测试文件里写
from mymodule import ValidationError，但实际异常定义在mymodule.errors.ValidationError - 误写成字符串
'ValidationError'当作异常类型传给assertRaises，会报TypeError: exception argument must be a class
最稳妥的方式是：在测试文件顶部明确导入，然后直接用类名，比如 self.assertRaises(ValidationError, ...)。
异常测试真正难的不是语法，而是想清楚“什么输入该触发什么异常”，这需要你比写代码时更懂边界和业务约束。漏掉一个空字符串、一个负数、一个 None，就可能让异常逻辑形同虚设。
