

新闻资讯
技术学院pytest通过扫描目录、导入测试文件并AST解析来收集test_*函数,import失败则静默跳过;scope决定fixture生命周期但受conftest层级影响;parametrize与yield fixture冲突因执行阶段不匹配;mock.patch需作用于引用位置而非定义位置。
pytest 是当前 Python 测试生态的事实标准,但直接套用文档示例常踩坑——比如 conftest.py 加载顺序混乱、parametrize 与 fixture 交互异常、或 pytest-xdist 并行时状态污染。真正稳住测试系统,得从它如何解析、收集、运行测试的底层链路入手。
不是靠文件名匹配完就结束。它先扫描
目录树,对每个 test_*.py 或 *_test.py 执行 import,再用 AST 解析出所有以 test_ 开头的函数和方法。若模块 import 失败(比如依赖未安装、语法错误),该文件直接被跳过,且默认不报错——你可能根本不知道某个测试文件压根没进执行队列。
pytest --collect-only 查看实际收集到哪些测试项,确认文件是否被识别pytest -v --tb=short 能暴露 import 阶段的异常,比静默跳过更有诊断价值scope 决定 fixture 实例的生命周期和复用边界,但很多人误以为 scope="session" 就等于“整个测试运行只调用一次函数”——其实它还受 conftest.py 层级和路径影响。跨目录时,同名 session 级 fixture 若在不同 conftest.py 中定义,会被视为两个独立 fixture。
scope="function":每个测试函数前 setup + 后 teardown,最安全,但开销大scope="class":类内所有测试共享一个实例,适合数据库连接等重资源,但需确保类内测试无状态干扰scope="module":注意模块级 fixture 在多文件间不共享;若需跨文件复用,统一提到项目根目录的 conftest.py
@pytest.mark.parametrize 在测试函数被收集时展开参数组合,生成多个测试节点;而 yield fixture 必须在运行阶段才执行 teardown 部分。两者叠加会导致 pytest 无法正确绑定 teardown 逻辑到每个参数化实例,抛出 ValueError: Setup yield fixture ... is not supported。
return + 显式清理(如 shutil.rmtree 放在 finally 块)替代 yieldscope="function" fixture,内部用 for 循环处理多组输入,返回单个结果pytest_generate_tests hook 替代装饰器,在收集阶段动态生成参数,完全绕过 yield 冲突常见写法是在 fixture 中用 @patch("xxx.yyy") 修饰函数,但 patch 只对被装饰函数生效;若 fixture 返回的是 mock 对象,而测试函数里又去 import 原模块,那 patch 根本没起作用——因为 patch 必须作用于“目标对象被引用的位置”,不是定义位置。
import pytest from unittest.mock import patch@pytest.fixture def broken_mock(): with patch("requests.get") as mock_get: mock_get.return_value.status_code = 200 yield mock_get # ❌ 错误:mock_get 是局部变量,测试函数中 requests.get 仍是原函数
def test_api_call(): import requests assert requests.get("http://x").status_code == 200 # 这里没被 mock
@patch("requests.get"),或在 fixture 中用 patch.object(requests, "get")
conftest.py 的 autouse fixture 里,并指定 scope="function",确保每次测试都重置requests.get 的 __module__ 和 __name__,确认它已是 Mock 类型pytest 的“自动”背后全是明确的收集规则、作用域链和执行时序。越想省事用高级特性,越要先看清它在哪一刻做了什么决定。那些看似随机的失败,往往只是某个 scope 没对齐,或某次 import 被静默吞掉了。