Python 单元测试设计与 pytest 实战

pytest自动发现测试需满足文件名（test_.py或_test.py）、函数名（test_开头）、类名（Test开头且无__init__）规则；fixture作用域选function防污染、session慎用；异常断言须用pytest.raises()上下文管理。

pytest 是当前 python 单元测试的事实标准，它比 unittest 更简洁、更灵活，也更容易写出可维护的测试。但直接照搬示例容易踩坑——比如测试函数名没加 test_ 前缀、fixture 作用域设错导致状态污染、或用 assert 检查异常却漏了 pytest.raises() 的上下文管理。

怎么让 pytest 自动发现并运行测试

pytest 默认只收集满足命名规则的函数和模块：文件名必须匹配 test_*.py 或 *_test.py，函数名必须以 test_ 开头。类名也要以 Test 开头（且不能带 __init__ 方法），否则会被跳过。

常见错误现象：

• 写了 def check_add(): —— 不会被识别
• 文件叫 math_utils.py —— 即使里面有 test_add 也不会运行
• 在非测试目录下执行 pytest —— 默认只搜当前目录及子目录下的测试文件

实操建议：

立即学习“Python免费学习笔记（深入）”；

• 统一用 test_ 前缀命名函数，如 test_add_two_positive_numbers
• 把测试文件放在 tests/ 目录，并在项目根目录放 pyproject.toml 配置 testpaths = ["tests"]
• 运行时显式指定路径：pytest tests/test_math.py::test_add 可精准调试单个函数

fixture 什么时候该用 function 而不是 session

fixture 的作用域（scope）直接决定它的生命周期和复用方式。用错 scope 是最隐蔽的测试污染源之一——比如数据库连接用 scope="session"，但多个测试修改了同一张表，后一个测试就可能因前一个残留数据而失败。

使用场景与选择依据：

• scope="function"：默认值，每个测试函数调用前新建、结束后销毁（适合临时对象、mock、独立状态）
• scope="class"：整个测试类共用一次 setup/teardown（适合类内多个测试共享轻量初始化）
• scope="module"：一个 .py 文件内所有测试共享（适合模块级配置，如读取一次 YAML 配置）
• scope="session"：整个 pytest 运行周期只初始化一次（仅限真正全局、只读、线程安全的资源，如远程 API Token）

性能影响：

• 过度使用 session 会让测试失去隔离性，CI 上偶发失败难复现
• 滥用 function（比如每次创建新数据库连接）会拖慢整体执行速度，此时应考虑 module + 显式清理

如何正确断言异常和警告

直接用 assert 判断异常是否抛出是错的，因为一旦没抛出，测试就崩溃退出，无法捕获异常类型和消息；而用 try/except 又冗长且易漏掉未预期异常。

正确做法是用 pytest.raises() 和 pytest.warns() 上下文管理器：

def test_divide_by_zero():     with pytest.raises(ZeroDivisionError, match="division by zero"):         1 / 0  def test_deprecated_function():     with pytest.warns(DeprecationWarning, match="use new_api instead"):         old_api()

关键点：

• match 参数支持正则，比简单字符串包含更可靠
• 不要写成 pytest.raises(ValueError) 后跟普通语句——必须用 with 包裹被测代码
• 如果想确保「不抛异常」，直接调用即可；若需显式声明，可用 with pytest.raises(Exception): assert False，但通常没必要

参数化测试中哪些参数组合该跳过

@pytest.mark.parametrize 很方便，但不是所有输入都要测。盲目覆盖全组合会导致冗余、慢、甚至触发非目标逻辑（比如给只接受字符串的函数传 None，结果测试的是类型检查而非业务逻辑）。

推荐跳过的典型情况：

• 明显非法但由上游校验拦截的输入（如 http 视图层已用 Pydantic 验证，单元测试就不必再喂 None 给内部 service 函数）
• 引发相同代码路径的重复值（如测试字典 key 是否存在，"a" 和 "b" 行为一致，选一个代表即可）
• 需要复杂前置条件才能触发的边界（如“磁盘满时写入失败”，这种更适合集成测试）

实操技巧：

• 用 ids 参数给每组参数起可读名：ids=["empty", "single", "multi"]
• 配合 @pytest.mark.skipif 动态跳过，比如 skipif=sys.platform == "win32"
• 避免在 parametrize 中写复杂表达式，参数尽量是字面量或常量，否则可读性和调试性骤降

最难的从来不是写测试，而是判断哪一行逻辑值得测、哪一行只是胶水代码、以及当测试失败时，你能否三秒内分清是实现错了，还是 fixture 没 clean 干净。