pandas.testing.assert_frame_equal用于严格验证数据清洗结果，需关注dtype、nan一致性、时间频率、边界脏数据构造及隔离随机性与外部依赖。
用 pandas.testing.assert_frame_equal 验证清洗结果是否符合预期
数据清洗逻辑一旦写错，下游分析可能全盘出错，但靠肉眼比对 DataFrame 几乎不可靠。最直接的办法是把清洗函数的输出和「已知正确」的参考结果做结构+值级比对。pandas.testing.assert_frame_equal 就是为此设计的——它默认检查索引、列名、数据类型、空值位置和数值精度（默认 check_exact=False，容忍浮点误差）。
常见错误现象：测试通过但实际逻辑有缺陷，比如漏处理某类空值、inplace=True 未生效却误以为修改了原数据、或字符串清洗时没设 regex=False 导致意外替换。
- 务必传入
check_dtype=False（除非你明确要验证 dtypes），否则int64和int32会被判为不等 - 若清洗后含
NaN，需确认参考数据中对应位置也是np.nan，而非字符串"NaN"或None - 对含时间列的清洗结果，加上
check_freq=False避免因频率推断差异失败
构造边界测试数据，覆盖真实清洗场景中的典型脏数据
清洗函数常在生产环境里遇到空字符串、混合空格、全角字符、嵌套引号、重复列名、时间格式混乱等。单元测试若只用干净数据，等于没测。
使用场景：比如清洗用户地址字段，必须显式构造含 " 上海 "、"上海\xa0"（NBSP）、"上海 "（全角空格）、"上海,," 的样本。
- 用
pd.DataFrame手动构造小数据，比从 CSV 加载更快、更可控 - 对字符串清洗，优先用
.str.strip().str.replace(r"\s+", " ", regex=True)而非.str.strip()单独调用，后者无法处理中间多余空格 - 测试缺失值填充逻辑时，同时覆盖
np.nan、pd.NA、None三种类型（Pandas 1.3+ 中行为略有不同）
避免在测试中依赖外部文件或全局状态
测试脚本执行失败，90% 是因为读取了本地路径下不存在的 CSV，或清洗函数内部调用了 pd.read_csv("raw_data.csv") 这类硬编码路径。
性能影响：每次测试都 IO 读文件，拖慢执行速度；兼容性影响：CI 环境无该路径，测试直接报 FileNotFoundError。
- 把原始脏数据定义为字典或列表，在测试函数内用
pd.DataFrame(...)构造，彻底去文件依赖 - 若清洗函数本身必须接收路径参数，测试时传入
io.StringIO模拟文件对象，例如：pd.read_csv(io.StringIO("a,b\n1,2")) - 不要在测试中修改全局
pd.options，如pd.set_option("mode.chained_assignment", None)，这会影响其他测试
对含随机性或时序依赖的清洗逻辑，隔离不确定性
比如用 df.sample(frac=0.8) 做训练集切分，或用 pd.to_datetime(df["ts"], errors="coerce") 处理模糊时间字符串，这类操作在不同 Pandas 版本或系统 locale 下行为可能漂移。
容易踩的坑：测试偶尔失败（flaky test），排查成本极高；或者本地通过、CI 失败，怀疑是环境问题，其实是逻辑本身不稳定。
- 对
sample类操作，固定random_state参数，如df.sample(frac=0.8, random_state=42) - 对时间解析，显式指定
format参数（如%Y-%m-%d %H:%M:%S），避免依赖自动推断 - 对 locale 敏感操作（如
str.capitalize()在土耳其语环境下行为异常），测试前用locale.setlocale(locale.LC_ALL, "C")锁定
真正难测的不是语法，而是清洗逻辑如何应对“人写的脏数据”——那些没写在文档里、但业务方每天都在填的奇怪格式。测试用例得像 QA 一样较真，才能让清洗函数在上线后少出一次线上事故。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
