pandas.read_csv 不该直接写在测试用例里，因其会引入外部文件路径、编码、网络及csv格式变化等不稳定依赖；应改用内存数据构造、stringio模拟或显式参数化输入。
为什么 pandas.read_csv 不该直接写在测试用例里
因为这会让测试依赖外部文件路径、编码、网络（如果读的是 URL）、甚至 CSV 格式微小变化，导致测试不稳定或无法本地运行。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 把数据构造逻辑抽成函数，比如
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
测试真正起作用的地方，往往不在 happy path 上，而在你懒得写的那条 except 分支里。