直接用 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)防止生成非法标识符
示例:生成一个模拟用户行为表
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)
<h3>绕过 <code>hypothesis</code> 对 <code>NaN</code> 的默认过滤</h3>
<p><code>hypothesis</code> 默认会跳过含 <code>NaN</code> 的测试用例(因为部分策略认为 <code>NaN != NaN</code> 导致比较失败),但这恰恰是 Pandas 测试最需要的场景。必须显式允许:</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill4102" title="Shadows Python Sensei"><img
src="https://img.php.cn/upload/skill/000/000/081/178990406882325.jpg" alt="Shadows Python Sensei" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill4102" title="Shadows Python Sensei" class="overflowclass">Shadows Python Sensei</a>
<p class="overflowclass">Python 最佳实践助手——代码规范、设计模式、性能优化、测试与类型注解。适用于编写或审查 Python 代码。</p>
</div>
<a rel="nofollow" href="/xiazai/skill4102" title="Shadows Python Sensei" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- 全局关闭:在测试模块开头加
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 而反复失败才意识到。
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!










