应显式列举空值、None、边界数字等异常输入，用@pytest.mark.parametrize逐一覆盖；需精确声明预期异常类型并用match校验消息；Unicode边缘case如BOM、零宽空格、代理对须硬编码测试。
pytest参数化怎么覆盖空值、None、边界数字这类异常输入
直接用 @pytest.mark.parametrize 列出具体值最稳妥，别指望靠随机生成来“撞”出问题。空字符串、None、负数、极大/极小浮点数、含控制字符的字符串——这些必须显式写进测试数据里。
常见错误是只测正常流程，比如传 "2023-01-01" 过得去，但漏掉 ""、None、"2023/01/01" 就可能在线上触发 AttributeError 或 ValueError。
- 把每个可疑输入单独列为一个
parametrize用例，哪怕看起来“重复” - 避免在参数列表里用表达式（如
str(1e300)），pytest 不会执行它，而是当字面量传入 - 如果多个测试共用同一组异常数据，提成常量，比如
INVALID_INPUTS = [None, "", -1, float('inf')]
如何让同一组参数同时验证多种异常类型（TypeError/ValueError/KeyError）
不能只写 with pytest.raises(Exception) ——这会掩盖真实问题。必须精确声明预期异常类型，否则 TypeError 和 ValueError 混在一起，后续改逻辑时容易误判。
使用 pytest.raises 的 match 参数可进一步约束异常消息，尤其对输入校验类函数很关键：比如区分 “expected int” 和 “must be positive”。
立即学习“Python免费学习笔记（深入）”；
- 每个异常输入配一个明确的
pytest.raises(TypeError)或pytest.raises(ValueError) - 用
match检查关键提示词：pytest.raises(ValueError, match="negative") - 别在
parametrize里混不同异常类型——拆成两个独立的parametrize块更清晰
用 pytest_generate_tests 自定义生成边缘 case 有哪些实际代价
除非你有几十种组合要穷举（比如协议字段 + 编码 + 长度），否则不建议用 pytest_generate_tests。它会让测试意图变模糊，调试时看不到原始参数来源，CI 报错也难定位是哪条生成规则出了问题。
真正省事的是封装好基础生成函数，再手动调用，而不是塞进钩子。比如写个 gen_overflow_ints() 返回 [2**31, 2**63]，然后放进 parametrize 列表里。
-
pytest_generate_tests适合统一注入环境变量或配置，不适合构造业务逻辑边缘值 - 生成逻辑一旦出错（比如漏了
0.0），所有依赖它的测试都静默跳过，比显式列值更难发现 - Pytest 7+ 对自定义 hook 的兼容性变差，某些插件会干扰参数生成顺序
字符串类函数测试中，哪些 Unicode 边缘 case 必须手动加
别信“覆盖了 ASCII 就够了”。Python 字符串操作在遇到 surrogate pair、BOM、零宽空格、组合字符时极易出错，而这些几乎不会被随机测试捕获。
典型问题包括 len() 和 str[0] 行为不一致、正则匹配失败、JSON 序列化报错。这些必须硬编码进 parametrize。
- 必加：
"\uFFFD"（replacement char）、"\uFEFF"（BOM）、"\u200B"（zero-width space） - 组合字符示例：
"n\u0303"（ñ 的分解形式），测试.lower()或.split()是否稳定 - surrogate pair 示例：
"\U0001F4A9"（?），验证切片、截断、编码是否崩
复杂点在于，同一个输入在不同 Python 版本里表现可能不同（比如 3.12 对 surrogate 处理更严格），所以这些 case 要保留注释说明覆盖意图，而不是靠工具自动推导。
