Python parametrize 与 hypothesis 的结合使用

pytest的@parametrize与hypothesis的@given本质冲突，不可混用；应使用st.one_of()、st.tuples()等组合策略在单个@given中实现多类型/多参数fuzz测试。

parametrize 里直接用 hypothesis 会报错

pytest 的 @pytest.mark.parametrize 和 hypothesis 的 @given 本质冲突：前者在收集阶段就确定所有测试用例，后者在运行时动态生成数据。硬套会导致 InvalidArgument: You can't use @given with @parametrize 或静默跳过 @given。

• 别写 @pytest.mark.parametrize(...); @given(...) 双装饰器——pytest 会忽略 @given，只跑 parametrize 的固定值
• 如果真需要“多组策略 + 每组内 fuzz”，得用 hypothesis.strategies.tuples() 或 st.one_of() 在单个 @given 里组合，而不是靠 parametrize 分流
• 常见误操作：把不同输入范围写成 parametrize 的几行，以为能触发 hypothesis 的 shrink —— 实际上每行只是独立调用一次 @given，shrink 只在该行内部生效，跨行不共享

想对同一函数测多种数据分布？用 strategy 组合，别用 parametrize

比如要分别验证整数、浮点、字符串三种类型输入下某个解析函数的行为，正确做法是定义一个统一 strategy，让 hypothesis 自己混合生成和缩小：

from hypothesis import given, strategies as st  @given(st.one_of(     st.integers(),     st.floats(allow_nan=False, allow_infinity=False),     st.text(max_size=10) )) def test_parser_accepts_various_inputs(value):     assert parse_input(value) is not None

• st.one_of() 让 hypothesis 在每次调用时随机选一类生成，失败时能自动缩小到最简反例（比如 -1 而不是 "abc"）
• 用 parametrize 写三组，等于手动写三个独立测试，每个都只能 shrink 自己那类数据，且无法发现跨类型的边界交互问题
• 注意 st.floats() 默认允许 nan 和 inf，实际业务中常要显式禁用，否则容易触发意外分支

需要固定参数 + fuzz 其他参数？用 composite strategy 或默认值

当某个参数必须是固定值（如 API 版本号 "v2"），其他参数要 fuzz，不要试图用 parametrize 绑定那个固定值——它会污染 hypothesis 的执行逻辑。

• 推荐方式：在 @given 内部用 st.just("v2") 或直接写死变量，配合其他 strategy 使用 st.tuples()
• 示例：

  @given(st.tuples(     st.just("v2"),     st.integers(min_value=1, max_value=100),     st.booleans() )) def test_api_call(version, user_id, include_meta):     assert call_api(version, user_id, include_meta) == "success"

• 避免在 @given 外层套 @pytest.mark.parametrize(version=["v1", "v2"]) —— 这会让 hypothesis 对每个 version 都重新初始化数据库状态、重置 seed，失去连续 shrink 能力

CI 环境下 hypothesis 行为突变？检查 database_file 和 derandomize

本地跑得好，CI 上 fail 得莫名其妙，大概率是 hypothesis 的数据库路径或随机性控制没对齐。

立即学习“Python免费学习笔记（深入）”；

• hypothesis 默认把 shrink 记录存在 .hypothesis/ 下，CI 容器每次重建，这个目录丢失 → 回退到原始随机生成，可能错过已知失败用例
• 解决方法：在 pytest 配置里加 --hypothesis-database-file=/tmp/hypothesis-db，确保跨构建可复现
• 开发时加 @settings(derandomize=True) 能让每次运行顺序一致，但 CI 不建议长期开启——它禁用部分优化策略，可能掩盖真实随机性 bug
• 另一个坑：max_examples 设太小（比如 @settings(max_examples=5)）在 CI 上因并发或资源限制，实际生成数更少，导致覆盖不足

hypothesis 的 shrink 是按测试函数粒度工作的，不是按 parametrize 的每一行；一旦混用，就等于放弃它最核心的价值。