直接用 pd.DataFrame 写测试数据不靠谱，因其难以覆盖空字符串、NaT、None、重复索引、非法列名等真实边界情况，且多列组合逻辑的手动穷举成本高；应使用 hypothesis[pandas] 的 dataframes() 策略并显式注入噪声和约束。
为什么直接用 pd.DataFrame 写测试数据不靠谱
当你手动构造几行 pd.DataFrame 去测一个清洗函数，比如 clean_user_data(df)，很容易漏掉边界情况：空字符串混在数值列里、NaT 和 None 同时存在、重复索引、列名含空格或点号。这些在真实日志或ETL管道中很常见，但手写测试几乎不会覆盖。
更麻烦的是，一旦逻辑依赖多列组合（比如“当 status 为 'active' 且 last_login 超过90天时标记为 stale”），手写数据要穷举组合成本陡增。这时候需要的是能自动探索输入空间的工具，而不是更多 pd.DataFrame(...)。
用 @given + dataframes() 生成带约束的真实结构
hypothesis[pandas] 提供了 dataframes() 策略，但它默认生成的列类型太“理想化”——全是非空、无缺失、类型干净。你需要显式注入现实噪声：
- 用
st.none() | st.text()模拟可能为空的字符串列 - 对时间列，用
st.datetimes(min_value=datetime(2020,1,1)) | st.just(pd.NaT) - 指定
index=st.integers(min_value=0)避免默认的RangeIndex掩盖索引相关 bug - 列名用
st.from_regex(r"[a-zA-Z_][a-zA-Z0-9_]*", fullmatch=True)防止生成非法标识符
示例：生成一个模拟用户行为表
立即学习“Python免费学习笔记（深入）”；
from hypothesis import given, strategies as st
from hypothesis.extra.pandas import dataframes, column
@given(
dataframes(
columns=[
column("user_id", dtype=int, elements=st.integers(1, 10000)),
column("email", dtype=str, elements=st.none() | st.emails()),
column("login_time", dtype="datetime64[ns]",
elements=st.datetimes(min_value=datetime(2022,1,1)) | st.just(pd.NaT)),
],
index=st.integers(min_value=0, max_value=1000)
)
)
def test_drop_inactive_users(df):
result = drop_inactive_users(df)
assert len(result) <= len(df)
assert "user_id" in result.columns
绕过 hypothesis 对 NaN 的默认过滤
hypothesis 默认会跳过含 NaN 的测试用例（因为部分策略认为 NaN != NaN 导致比较失败），但这恰恰是 Pandas 测试最需要的场景。必须显式允许：
- 全局关闭：在测试模块开头加
settings(suppress_health_check=[HealthCheck.filter_too_much]) - 对单个列，用
elements=st.floats(allow_nan=True, allow_infinity=False)或st.none() | st.floats(...) - 避免在断言中直接用
==比较含NaN的 Series，改用pd.testing.assert_series_equal(a, b, check_names=False)
否则你会看到大量 Unsatisfiable: unable to satisfy filter 报错，误以为策略写错了，其实是 hypothesis 主动丢弃了它觉得“危险”的样本。
性能陷阱：别让 hypothesis 生成超大 DataFrame
dataframes() 默认不限制行数，如果没设 max_size，可能生成上万行导致单测跑几十秒甚至 OOM。真实单元测试不需要大数据量，需要的是高变异度的小样本：
- 用
max_size=50控制总行数（不是每列） - 对宽表（>20 列），用
columns=st.lists(..., min_size=3, max_size=8)限制列数 - 若被测函数本身有性能敏感逻辑（如
groupby().apply()），在测试里加@settings(max_examples=20)降频
记住：单元测试的目标是暴露逻辑漏洞，不是压测。生成 5 行但包含 NaN、NaT、空字符串、负数 ID 的数据，比生成 5000 行全正整数的数据更有价值。
真正难的是让生成器理解业务约束——比如“email 列非空时必须含 @ 符号”，这得靠自定义 st.builds() 或 st.from_regex()，而不是依赖默认策略。这点容易被忽略，直到某次 CI 因为生成了 100 个无效 email 而反复失败才意识到。
