pandas.read_csv 不该直接写在测试用例里，因其会引入外部文件路径、编码、网络及csv格式变化等不稳定依赖；应改用内存数据构造、stringio模拟或显式参数化输入。
为什么 pandas.read_csv 不该直接写在测试用例里
因为这会让测试依赖外部文件路径、编码、网络（如果读的是 URL）、甚至 CSV 格式微小变化，导致测试不稳定或无法本地运行。
实操建议：
立即学习“Python免费学习笔记（深入）”；
LANUX蓝脑商务网站系统
下载
LANUX V1.0 蓝脑商务网站系统 适用于网店、公司宣传自己的品牌和产品。 系统在代码、页面方面设计简约，浏览和后台管理操作效率高。 此版本带可见即可得的html编辑器, 方便直观添加和编辑要发布的内容。 安装： 1.解压后，更换logo、分类名称、幻灯片的图片及名称和链接、联系我们等等页面。 2.将dbconfig.php里面的数据库配置更改为你的mysql数据库配置 3.将整个文件夹上传至
- 把数据构造逻辑抽成函数，比如
make_test_dataframe()，用pd.DataFrame直接生成干净的内存数据 - 若必须测真实读取逻辑，把 CSV 内容固化为字符串，用
io.StringIO模拟文件句柄，避免磁盘 I/O 和路径问题 - 别在
setUp或测试函数里调用read_csv读取相对路径——CI 环境工作目录可能和本地不一致
如何让自定义清洗函数支持单元测试
核心是剥离副作用：把数据输入、参数、输出三者完全显式化，不隐式依赖全局变量、配置文件或数据库连接。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 清洗函数只接收
df: pd.DataFrame和必要参数（如date_col: str），返回新df，不修改原地 - 避免在函数里调用
logging.info或print——它们会干扰断言，也增加 mock 成本 - 如果要用配置，通过参数传入字典或 dataclass 实例，而不是读
config.yaml - 示例：
def clean_sales(df, cutoff_date: str = "2023-01-01") -> pd.DataFrame:，这样可直接用不同cutoff_date覆盖边界场景
pytest.mark.parametrize 怎么用才不翻车
它适合验证同一函数在多组输入下的行为一致性，但容易因数据结构嵌套过深或异常类型不匹配导致断言失败难定位。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 每组参数控制在 3–4 个字段内，用命名元组或字典封装，避免位置错乱；例如传
{"input": [1,2,3], "expected": 6}而不是([1,2,3], 6) - 如果要测异常，用
pytest.raises(ValueError)显式包裹调用，别靠assert "error" in str(e) - 避免在
parametrize中传入未序列化的对象（如datetime.now()），会导致每次运行值不同，测试不可重现 - 参数名别用
data这种泛称，改用invalid_phone_str、empty_df_input等能一眼看懂意图的名称
mock 外部 API 调用时最常漏掉的一件事
只 mock 返回值，却没 mock 异常路径——结果线上报错，测试却全绿。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 对每个外部依赖（比如
requests.get），至少写两组测试：正常响应 + 一种典型异常（requests.Timeout或HTTPError） - 用
side_effect而非return_value来模拟异常：mock_get.side_effect = requests.Timeout("test") - 检查被测函数是否真的处理了异常——比如有没有
try/except，有没有 fallback 逻辑，别只验证“没崩”，要验证“返回了预期 fallback 值” - 如果函数内部用了
session.get而不是requests.get，mock 的目标得是your_module.session，不是requests
except 分支里。 
