pytest fixture进阶：autouse机制与scope执行顺序

做自动化测试的同行应该都有这种感觉pytest的 fixture 刚上手时觉得特别简单无非就是写个pytest.fixture装饰器然后在测试函数里当参数传进去。但用着用着就发现不对劲尤其是autouseTrue这个参数有时候用例莫名其妙多跑了一些逻辑有时候明明写了 fixture 却总是不执行去翻源码又看不懂它的调度规则最后只能靠打日志猜。今天我专门把 fixture 的进阶玩法以及 autouse 的完整行为机制掰开揉碎讲清楚。这篇文章不是入门教程需要你已经写过至少几十个 fixture、跑过实际项目能理解 scope、yield、conftest 这些基础操作。读完以后你会彻底弄清楚 fixture 的执行顺序、作用域边界、隐式触发规则以及怎么用工厂模式和内置 fixture 写出稳定的测试代码。1. fixture 的底层逻辑它不只是 setup/teardown 的替代品1.1 fixture 本质上做的是状态安装与卸载两件事很多从unittest转过来的同学习惯把 fixture 理解成setUp和tearDown的替代品。这没有错但容易把思维限制住。unittest的 setUp/tearDown 是强行绑定在测试类上的每个测试方法都得继承同一个基类灵活性很差。而pytest的 fixture 真正厉害的地方在于它是一个被依赖注入的、可组合的状态管理单元。用最生活化的类比来理解你开一家餐厅每个客人来吃饭测试函数运行都需要先擦桌子准备工作、上菜执行测试、再收拾餐具清理工作。在unittest时代你只能规定所有餐桌必须按同一套流程招待而 fixture 则是把擦桌子、上菜、收拾都拆成独立的服务模块这个客人需要擦桌子就注入擦桌子功能那个客人需要环境消毒就注入消毒功能彼此互不干扰。# 一个最普通的 fixture pytest.fixture def db_conn(): conn create_connection() # 安装状态 yield conn # 测试执行期间使用 conn.close() # 卸载状态这里的安装和卸载可以是任何东西连接数据库、创建临时文件、设置环境变量、启动mock服务甚至只是往内存里塞一个配置对象。yield之前是准备逻辑yield之后是清理逻辑测试函数的执行过程被精确地夹在中间。这种生命周期管理就是 fixture 存在的基本意义。1.2 fixture 能解决哪几类真实问题在实际测试项目里fixture 解决的远不止简化清理这一件事。我总结下来至少有四类高频场景隔离测试环境。每个测试需要独立的临时目录、独立的配置、独立的mock服务器fixture 可以天然保证这种隔离性。比如用tmp_path内置 fixture每个测试都能拿到一个全新的空目录测试之间互相不污染。共享重量级资源。数据库连接池、浏览器实例、Redis 连接这种启动慢、耗费大的资源如果每个测试都新建一个整个测试套件可能慢到无法接受。fixture 通过scopesession或scopemodule让这些资源在整个测试周期内只初始化一次性能提升是肉眼可见的。解除测试代码对底层细节的依赖。我经常在 fixture 里统一处理测试数据的生产逻辑测试函数本身只需要声明我要一个用户对象而不需要关心这个用户对象是数据库里查出来的、还是内存对象、还是通过API创建的。一旦数据来源变化只需要改 fixture所有测试函数零改动。统一嵌套解耦的清理动作。多个 fixture 可以互相依赖一个 fixture 执行结束后自动触发下一个 fixture 的安装和卸载形成一种洋葱模型。外层 fixture 负责全局环境内层 fixture 负责具体数据yield 之间形成严密的嵌套关系任何一层出异常都能保证清理逻辑按预期执行。说句实在话如果只用 fixture 做简单的资源准备那和 setUp/tearDown 本质没有区别只是换了个语法糖。真正体现 fixture 价值的是组合和依赖注入。当你把被测系统的所有外部依赖都抽象成 fixture测试代码将是极其干净的——每个测试函数只干一件事读起来像需求文档一样清晰。2. fixture 进阶玩法scope、参数化与组合依赖2.1 scope 用不对测试就等着踩坑scope参数决定 fixture 的生命周期它接受四个值function默认、class、module、session。很多人只记住了function 级别每个测试执行一次session 级别整个测试过程执行一次但实际工程里的选择细节远没有这么简单。我直接给一个使用了所有 scope 的完整示例import pytest import sqlite3 pytest.fixture(scopesession) def db(): # 整个测试周期只创建一次数据库连接 conn sqlite3.connect(:memory:) conn.execute(CREATE TABLE users (id INTEGER, name TEXT)) yield conn conn.close() pytest.fixture(scopemodule) def module_data(db): # 每个模块执行一次依赖于 session 级 db cursor db.cursor() cursor.execute(INSERT INTO users VALUES (?, ?), (1, Alice)) db.commit() return {module: data ready} pytest.fixture(scopeclass) def class_config(): # 每个测试类执行一次 return {env: test} pytest.fixture(scopefunction) def fresh_data(): # 每个测试函数独立的数据 return {counter: 0}这里有个关键问题scope 的层级是严格嵌套的。一个session级的 fixture 可以被module、class、function级的 fixture 依赖反过来不行。因为高层级 fixture 的生命周期必须先于低层级开始、晚于低层级结束如果你让一个function级的 fixture 被一个session级的 fixture 依赖pytest 会直接报错。这个设计逻辑上是严谨的不是 pytest 故意限制你session 级的创建时机是在整个测试会话启动阶段而 function 级的 fixture 必须等具体测试函数运行时才能生成两者的生命周期根本没有交集。实际工程中最容易踩的坑是scopemodule和scopesession产生的状态污染。举一个我踩过的真实案例一个列表类型的 fixture 用scopesession里面预先放了几个测试数据然后第一个测试函数运行后往列表里append了一条新数据第二个测试函数跑的时候发现数据已经不是最初的状态了。这种 bug 极其难排查因为你单跑第一个测试用例时它是绿的单跑第二个也是绿的但是两个一起跑就挂了。经验法则当你使用非 function 级别的 fixture 时必须保证这个 fixture 返回的对象是只读的或者每个使用方都只能创建自己的副本绝不能让测试直接修改共享对象的内容。如果确实需要共享可变状态就在 yield 之前深拷贝一份让每个测试拿到独立副本。另外要说一下性能收益的度量。session 级 fixture 省下的是初始化时间但这个收益只在资源初始化耗时占测试总耗时比例较高时才值得换取状态污染风险。如果初始化只要 10 毫秒你用 session 级就完全没有必要老老实实用 function 级每个测试都拿到全新状态不用动脑子。2.2 参数化 fixture一条测试函数自动跑多份数据params参数让 fixture 变成一个数据源每次测试执行时pytest 都会从params列表里取一个值通过request.param传给 fixture。核心价值在于一个测试函数逻辑可以自动被复制成多份对每一组参数分别跑一遍。pytest.fixture(params[mysql, postgresql, sqlite]) def db_engine(request): if request.param mysql: engine create_mysql_engine() elif request.param postgresql: engine create_pg_engine() else: engine create_sqlite_engine() yield engine def test_query(db_engine): # 这个测试会自动跑 3 遍分别使用三种数据库 result db_engine.query(SELECT 1) assert result 1很多初学者分不清 fixture 参数化和pytest.mark.parametrize的区别。一句话总结如果你要在多个测试函数里复用同一组数据源配置优先用 fixture 参数化如果你只针对某一个测试函数进行多组输入输出验证用 parametrize 更合适。fixture 参数化是把环境的多样性抽离出来parametrize 是把业务逻辑的输入输出组合写清楚。fixture 参数化和pytest.mark.parametrize同时使用时会生成笛卡尔积。比如 fixture 有 3 个参数mark 标记有 2 组参数最终会产生 6 个测试用例。这个乘法关系用多了以后测试报告里会出现大量测试项建议给每一组参数加一个id否则报告里显示的是db_engine[mysql0]这种难看且难以辨认的名字。pytest.fixture(params[ pytest.param(mysql, idmysql_conn), pytest.param(postgresql, idpg_conn), pytest.param(sqlite, idsqlite_conn), ]) def db_engine(request): yield request.param参数化 fixture 还有一个妙用你可以用params模拟多个环境配置比如同一个测试在debug模式和release模式下都要通过。把配置字典作为 params 传入测试函数里就不用写任何环境判断逻辑。这个思路在接口测试项目里特别实用一套用例跑 staging 环境一套数据、跑生产环境另一套数据只是切换 fixture 的 params测试代码一行不动。2.3 fixture 之间的依赖与工厂模式组合才是王道fixture 调用 fixture 是 pytest 最强大的组合机制。一个 fixture 可以直接声明对其他 fixture 的依赖pytest 会自动解析依赖树并保证执行顺序。这种组合再配合 yield 机制能实现非常优雅的资源嵌套管理。pytest.fixture(scopesession) def api_client(): client APIClient(base_urlhttps://api.example.com) client.login(admin, password) yield client client.logout() pytest.fixture def project(api_client): # 依赖于 api_client自动复用同一个登录会话 data api_client.create_project(nametest-project) yield data api_client.delete_project(data[id]) def test_project_permission(project, api_client): # 同时拿到 project 和 api_client resp api_client.get_project(project[id]) assert resp[name] test-project执行顺序上pytest 时会先进入api_client的初始化再进入project的初始化测试函数运行结束后先执行project的清理再执行api_client的清理。这就是典型的洋葱模型后初始化的先清理先初始化的后清理保证依赖关系不会在清理阶段被打破。更进阶的玩法是工厂模式。有时候一个 fixture 不只是提供一个对象而是提供一个生产对象的方法。这个方法可以在测试函数内部被多次调用每次产生不同的数据。工厂模式的核心是 fixture 返回一个函数而不是数据测试函数在需要的时候自己调用这个函数。pytest.fixture def user_factory(): # 注意这里接收一个参数使用内部嵌套函数 def _create_user(name, age18, is_adminFalse): user User(namename, ageage) if is_admin: user.add_role(admin) return user return _create_user def test_user_permission(user_factory): alice user_factory(Alice) admin_bob user_factory(Bob, is_adminTrue) assert alice.can_edit() is False assert admin_bob.can_edit() is True工厂模式最大的优点是灵活性。普通 fixture 在每个测试函数里只能拿到一个固定的对象工厂模式让你可以在一个测试里创建任意多个不同配置的对象适用性广得多。代价是清理逻辑需要你自己控制——因为 pytest 不知道工厂方法创建了什么没法自动清理。我的习惯是让工厂方法内部注册一个清理回调列表测试结束前手动触发或者把清理逻辑封装在工厂方法底层比如通过 with 语句管理资源生命周期。3. autouse 行为彻底拆解隐式执行的完整机制3.1 autouse 的本质一个不需要显式请求的自动插件autouseTrue会让 fixture 在不求显式声明的情况下自动执行。它的作用对象是所有处在它作用域范围内的测试。这里的作用域范围由 fixture 定义的位置即 conftest 文件的层级和 scope 参数共同决定。需要特别强调autouse 并不意味着每个测试都会以装饰器注册的方式执行而是pytest 在收集并准备测试时会隐式地把它加入到每个测试的依赖列表里。你可以把它理解成pytest 把这些 fixture 安装成了一个测试环境插件自动装配在每个测试节点上。看这个最基础的例子import pytest import time pytest.fixture(autouseTrue) def timer(): start time.time() yield elapsed time.time() - start print(ftest took {elapsed:.3f} seconds)任何测试函数只要跟这个 fixture 在同一个 conftest 范围内运行的时候都会自动执行计时逻辑。测试函数本身完全无感知不需要写任何参数。这就是隐式执行。autouse 最常见的应用场景包括打日志记录运行时长、检查环境变量是否存在、清理临时目录残留、统一设置系统时区、注入全局 mock 对象、统计测试执行轨迹。这些逻辑与业务无关但又必须每次都执行显式声明会污染测试函数的签名用 autouse 刚好。3.2 autouse 的生效范围conftest 层级决定一切autouse 的生效范围不取决于测试文件本身而取决于conftest.py所在的目录层级。conftest.py是 pytest 的目录级配置和 fixture 定义中心pytest 读取 conftest 的规则是从测试文件所在目录开始逐级向父目录查找把所有 conftest.py 合并进作用域。目录结构如下tests/ ├── conftest.py # 全局影响下面所有目录 ├── test_system.py ├── test_api/ │ ├── conftest.py # 只影响 test_api 目录下 │ ├── test_users.py │ └── test_orders.py └── test_web/ ├── conftest.py # 只影响 test_web 目录下 └── test_pages.py如果tests/conftest.py里定义了pytest.fixture(autouseTrue, scopefunction)那么test_system.py、test_api/test_users.py、test_web/test_pages.py里的所有测试都会自动执行这个 fixture。如果test_api/conftest.py里定义了 autouse fixture它只会影响test_api目录下的测试test_web目录完全不受影响。这个机制容易踩的第一个坑是autouse fixture 在 conftest 树中的优先级不是就近覆盖而是全部生效。如果全局 conftest 定义了env_check子目录 conftest 也定义了同名env_check不会出现子目录覆盖全局的效果而是子目录的 fixture 会轮到自己执行全局的也会执行。如果你的意图是覆盖需要在子目录 conftest 里使用同名 fixture并且在定义时不要写 autouse而是让子目录测试显式传入——这样 pytest 的就近优先规则才会让子目录版本生效。第二个坑是 scope 与目录层级的叠加效应。pytest.fixture(autouseTrue, scopesession)定义在全局 conftest 里整个测试 session 只执行一次并不是每个测试前都执行。很多初学者以为 autouse 永远是 function 级别的这就错得离谱了。autouse 可以搭配任何 scope但行为差异非常大。# 全局 conftest.py pytest.fixture(autouseTrue, scopesession) def global_setup(): # 整个测试周期只执行一次不是在每个测试用例前执行 print(Global session setup) yield print(Global session teardown)这里的要点是session 级 autouse 的 yield 之前逻辑会在所有测试执行前一次性运行yield 之后逻辑在所有测试结束后运行。如果你期望它每次测试前都重置数据库那就彻底错了数据库只会在第一个测试前重置一次后面的测试之间不会重置。第三个坑是autouse fixture 在模块内定义 vs 在 conftest 内定义的区别。如果你在test_users.py文件里直接定义一个pytest.fixture(autouseTrue)的 fixture它只影响本文件内的测试不会影响其他文件但注意一点测试文件内定义的 autouse fixture 实际上也是被 pytest 当作模块级插件来装配的效果等同于 conftest 但作用范围更窄。实践中我更倾向于把重要的 autouse 放到 conftest 而不是测试文件里这样跨文件复用性更好其他人找环境配置也方便。3.3 autouse 与普通 fixture 的执行顺序排队规则比你想的复杂很多人在面试或写复杂测试时被问到一个问题如果同时存在 autouse fixture 和显式请求的 fixture谁先执行 答案不是简单的autouse 先而是由三条规则共同决定规则一scope 越大越先执行。session 级别的 fixture 必然先于 module 级别执行module 级别先于 function 级别。autouse 并不是在排序上凌驾于这个规则之上的它只是在同 scope 的队列里靠前而已。规则二在同一个 scope 内autouse fixture 优先于显式请求的 fixture。但有一个例外——如果显式请求的 fixture 依赖另一个 fixture那被依赖的 fixture 会先执行即使它是普通 fixture。规则三多个 autouse 的彼此顺序按照 conftest 层级从高到低、文件定义从前往后的顺序执行。用一个完整示例来验证import pytest pytest.fixture(autouseTrue) def auto_fn(): print(autouse function-level) yield pytest.fixture def normal_1(): print(normal fixture 1) yield pytest.fixture def normal_2(normal_1): print(normal fixture 2, depends on normal_1) yield def test_order(normal_2): print(test running) assert True实际输出顺序是autouse function-level normal fixture 1 normal fixture 2 test runningautouse 先于 normal_2 执行为什么呢虽然 normal_2 被显式请求但它的依赖 normal_1 需要先执行而 autouse 是同 scope 内不依赖任何东西的自由节点所以先被调度。如果 autouse 本身依赖一个普通 fixture那么被依赖的普通 fixture 会优先。比如pytest.fixture(autouseTrue) def auto_with_dep(normal_1): print(autouse depends on normal_1) yield这种情况下normal_1会先执行然后是 autouse。实际工程中如果要精确控制 autouse 和普通 fixture 的执行顺序最佳实践是让 autouse 不依赖任何业务 fixture保持它的环境初始化纯粹性。一旦 autouse 开始依赖其他 fixture它的调用关系就变得不直观排查问题时要追踪的依赖链也越来越复杂。3.4 autouse 应该怎么用哪些场景该用哪些场景绝对别用结合我带团队的经验autouse 是一把双刃剑。它的优点是省事缺点也是省事——隐式代码最可怕的不是行为本身而是团队成员看到测试文件时根本不知道还有这些隐式逻辑在运行。新同学接手项目跑了一个测试但搞不懂为什么有环境变量被设置了查了半天才发现是 conftest 里的 autouse 在起作用。这种魔法行为在维护大型测试项目时会显著增加认知负担。我的使用建议是适合用 autouse 的三类场景第一横切关注点cross-cutting concern。计时、日志、环境检查、全局 mock 这类与任何具体测试业务无关、但又必须保证每个测试稳定的逻辑是最适合 autouse 的。它们不产生业务数据不改变被测系统的核心状态属于锦上添花的辅助逻辑。第二低成本无副作用的全局状态准备。比如确保某个环境变量被设置、确保某个临时目录为空、确保系统时区为 UTC。这些操作天然具备幂等性即使在多个 autouse 之间组合也不会产生叠加污染。第三基础环境的全局 mock。比如把所有测试都强制设置成使用本地时间、把所有网络请求都重定向到测试服务器。这类测试环境预设定通常放在 session 级 autouse 里全项目统一生效。千万不要把以下 fixture 设为 autouse第一产生业务测试数据的 fixture。比如创建用户对象、创建订单、插入数据库记录。这类 fixture 带有明显的业务意图测试函数需要清楚自己用了什么数据如果隐式插入用例读起来就会缺少信息量而且很容易因为 autouse 产生测试数据互相干扰。第二高成本资源初始化的 fixture。比如启动一个浏览器实例、建立一个大文件下载连接。如果这个资源不是每个测试都真正需要autouse 会让所有测试都白白承担这些成本测试套件整体时间会急剧膨胀。第三带有参数化的 fixture。autouse 和params结合时每个参数组合都会让所有测试自动复制成多份。如果你的参数列表有 5 个数据库配置那么整个项目所有测试都会自动变成 5 倍数量。这通常不是你想要的——除非你确定整个项目真的必须在 5 种配置下全部跑一遍。我实际踩过的一个教训是为了图方便把一个创建测试用户的 fixture 设置成 autouse结果项目里所有模块的测试全都隐式依赖了一个用户已存在的假设。后来有测试需求要验证用户不存在时的场景发现无论怎么操作autouse 都会先创建一个用户导致这个场景永远无法覆盖。最后只能去掉 autouse改成显式请求并重写了那批用例。从那以后我给自己定了一条规矩凡是用例需要感知其存在状态的 fixture一律禁止 autouse。4. 内置 fixture 与 request 对象把 pytest 的能力榨干4.1 request 对象测试上下文的万能钥匙每个 fixture 函数实际上都可以接收一个名为request的特殊 fixture它就是当前测试请求的完整上下文对象。通过它你可以拿到测试节点信息、参数化数据、命令行配置、标记信息等等。pytest.fixture def user(request): # 获取参数化数据 param request.param if hasattr(request, param) else None # 获取测试函数名称 test_name request.node.name # 获取命令行配置项 env request.config.getoption(--env, defaulttest) # 获取 marker 标记信息 marker request.node.get_closest_marker(slow) if marker: print(fTest {test_name} is marked as slow) return {param: param, env: env, test: test_name}在爬虫或接口测试项目里request.config几乎是必用的通过命令行参数传入接口地址的基准 URL、传入不同环境的 TOKEN、传入需要排除的测试用例编号。fixture 里读取这些配置后整个测试套件就能灵活适配多种环境。# conftest.py def pytest_addoption(parser): parser.addoption(--base-url, actionstore, defaulthttps://staging.example.com, helpEnvironment base URL) pytest.fixture(scopesession) def base_url(request): return request.config.getoption(--base-url)4.2 工厂 fixture 模式动态创建测试数据的最优解前面提到了工厂模式的基础写法这里我想深入讲一些实用细节。工厂 fixture 最典型的应用场景是创建带依赖关系的数据链条。以一个完整的中型管理系统测试为例用户关联了多个角色角色关联了多个菜单权限测试删除用户时可能要验证这个用户的角色也被清理。pytest.fixture def service_data_factory(db_session): created_records [] def _factory(**kwargs): # 创建用户 user User(namekwargs.get(name, default_user)) db_session.add(user) db_session.flush() # 创建角色 role Role(namekwargs.get(role_name, viewer), user_iduser.id) db_session.add(role) db_session.flush() # 组合返回 instance {user: user, role: role} created_records.append(instance) return instance yield _factory # 批量清理 for record in created_records: db_session.delete(record[user]) db_session.commit()这里的关键点是created_records列表记录了所有工厂调用产生的记录清理阶段一次性删除全部。工厂模式配合清理逻辑是保证测试数据不污染数据库的核心手段。我的习惯是只要工厂方法创建了任何有状态的资源就必须在同一个 fixture 里完成跟踪和清理不把清理责任丢给测试函数。4.3 内置 fixture 实战tmp_path、capsys、monkeypatch、caplogpytest 提供了非常实用的内置 fixture很多人在写用例时不知道用导致测试代码冗长。我挑几个高频的逐一说明。tmp_path是 pytest 自动管理的临时目录 fixture每个测试函数独享一个全新目录测试结束后自动清理。用它来测试文件读写逻辑比手动创建临时目录、再手动删除要安全得多。def test_file_save(tmp_path): target_file tmp_path / data.txt save_data(target_file, hello) assert target_file.exists() assert target_file.read_text() hellocapsys能捕获 stdout 和 stderr适合测试命令行程序或日志输出逻辑。注意它捕获的是字节流输出要在capsys.readouterr()之后做断言。def test_print_output(capsys): print(hello world) captured capsys.readouterr() assert captured.out hello world\nmonkeypatch是动态修改对象和环境的利器。它可以临时替换函数、属性、环境变量测试结束后自动还原。比如测试一个读配置文件的函数但文件不存在你就可以 monkeypatch 掉open函数内部逻辑来模拟文件不存在而不用真的去删文件。def test_config_missing(monkeypatch): def raise_filenotfound(*args, **kwargs): raise FileNotFoundError(mock missing) monkeypatch.setattr(builtins.open, raise_filenotfound) with pytest.raises(FileNotFoundError): load_config(/nonexistent/path)caplog可以捕获并断言日志输出非常适合测试业务代码里的 logger 行为。def test_log_message(caplog): import logging with caplog.at_level(logging.INFO): do_something_with_logging() assert operation started in caplog.text还有一个容易被忽略的是requestfixture 的request.node它可以拿到当前测试函数的 marker 和参数化信息。在做测试报告增强时经常用它来动态判断当前用例是否被标记为冒烟测试然后决定是否跳过某些重量级 fixture。这种测试感知式 fixture 可以让测试框架更智能。5. 常见问题与排查技巧实录我做测试框架维护这几年总结了一套 fixture 相关故障的排查清单。很多问题看起来诡异其实原因就那么几种按顺序排查基本几分钟就能定位。问题一FixtureNotFoundError报错信息通常是fixture xxx not found。排查思路先确认拼写是否一致特别是大小写和下划线其次确认 fixture 定义位置是不是 conftest.py 且 conftest 层级在当前测试文件向上能找到的范围内。一个经典坑是把 fixture 定义在tests/conftest.py但实际上跑的是tests/api/test_users.py的测试这没问题因为逐级向上能找到但如果 fixture 定义在tests/api/conftest.py而测试文件在tests/下或者tests/system/下那就找不到了——conftest 只对自身目录及以下生效。还有一种情况是 fixture 的 scope 依赖关系不正确比如 session 级 fixture 内部试图 yield 一个 function 级 fixturepytest 在收集节点时就会报错。问题二测试用例执行顺序莫名其妙测试里打印的顺序和直觉不一致比如一个用例里看到别的 fixture 的数据被修改。这类问题 90% 是 scope 设置过大导致的剩余 10% 是 autouse 在暗中影响。排查方法是给每个 fixture 的init或 yield 处加打印语句跑一次带-s的测试看实际执行顺序。注意pytest -s能让你看到所有 print 输出但大量日志混在一起也不好分辨建议用一个带前缀的日志函数比如print([FIXTURE:db] init)这样 grep 起来方便。定位到顺序问题后再检查 fixture 的 scope 是否最小化以及是否有必要让某些 fixture 互相依赖。问题三autouse 没有按预期执行这个分两种情况。第一种是你以为它应该全局生效但它其实只存在于某个子目录 conftest第二种是你设置成 session 级 autouse结果只在 session 开头执行了一次你后来期望每个 test 都执行却没执行。排查时先确定 autouse 所在 conftest 的目录层级再检查 scope。此外还有个不常见但真实存在的坑如果测试文件里的pytestmark pytest.mark.usefixtures(某个fixture)这只会把那个 fixture 显式加到用例前置条件里并不会让autouse失效但如果这个 mark 的 fixture 依赖了 autouse 没有定义的子级配置可能表现出没执行的假象。建议遇到 autouse 异常时第一反应就是加一个断点或者利用--setup-show参数查看 pytest 实际加载的 fixture 链。问题四测试数据库/共享数据被污染典型的症状是单跑用例 A 通过单跑用例 B 通过A 和 B 一起跑就 B 失败。这种八成是 A 修改了某个可变的共享 fixture 对象B 读的时候拿到的是被 A 改过的状态。解决办法是让共享 fixture 返回该对象的深拷贝或者降低共享 fixture 的 scope或者在 yield 里做快照恢复。如果不方便改变 scope就写一个 reset 函数在 yield 之后把状态重置。我最常用的方案是共享 fixture 里不直接返回原始对象而是返回一个包装类包装类每次读都从源头获取最新状态避免缓存过期。问题五修改 fixture 返回值但不生效场景是这样的测试函数里拿到 fixture 返回的对象然后修改了对象的属性但下一个测试函数或者断言里发现修改没生效。这通常是因为 fixture 是 function scope 但返回的是同一个单例对象的引用。比如你的 fixture 每次都返回同一个配置字典那第一个测试修改它第二个测试拿到的还是同一个被改过的字典。验证方法很简单在测试函数里打id()看两个测试拿到的对象内存地址是否一致。如果一致说明是单例共享需要让 fixture 返回一个副本。如果 scope 是 session/module这种现象就更常见了因为对象在很长的生命周期里只创建一次。问题六class 中使用 fixture 的限制很多从 unittest 转过来的人想在测试类的__init__方法里使用 fixture这是不行的——pytest 的 fixture 注入要求只能发生在测试函数或测试方法的参数声明里__init__不是 pytest 管理的执行节点。正确的做法是用 pytest 的类风格测试在测试方法参数里声明 fixture或者用pytest.mark.usefixtures让整个类的所有测试方法前置加载 fixture。pytest.mark.usefixtures(db_conn) class TestUserAPI: def test_get_user(self): # db_conn 已经自动注入不需要在参数里声明 pass问题七并发测试下 fixture 的行为如果你的测试套件用了 pytest-xdist 或 pytest-parallel 跑并发session 级 fixture 会在每个 worker 中各自执行一次而不是全局一次。这个行为很容易被误解。如果你期望所有 worker 共享一个资源比如只启动一次 mock 服务器那 session 级 fixture 根本做不到因为每个 worker 是独立进程内存不共享。正确做法是把 mock 服务器启动逻辑放到 pytest_configure 钩子里或者启动一个进程外的真实服务再让所有 worker 连接同一个地址。这也是很多人用 pytest-xdist 时遇到 fixture 不生效或重复执行的根因。我还想补充一个排查技巧不要只靠看代码猜执行顺序强烈建议用pytest --setup-show跑一下测试。这个参数会显示出每个测试运行时的 fixture setup/teardown 清单包括 autouse 都会列出。看到实际执行清单远比靠脑内推演靠谱得多。tests/test_system.py::test_order SETUP S auto_fn (fixtures used: ) SETUP F normal_1 (fixtures used: ) SETUP F normal_2 (fixtures used: normal_1) tests/test_system.py::test_order (fixtures used: auto_fn, normal_2) TEARDOWN F normal_2 TEARDOWN F normal_1 TEARDOWN S auto_fn这个输出能清清楚楚看到谁是 setup 谁先 teardown排查执行顺序问题时我第一步永远是跑这个命令而不是去翻 fixture 定义源码。最后再分享一个小技巧。如果项目中 fixture 数量多了之后想知道当前有哪些 fixture 可用直接用pytest --fixtures命令它会列出所有可见的 fixture 名称、所在文件和 docstring。这个命令还支持在 conftest 中通过pytest_fixture_setup钩子做更精细的控制但日常用这个命令辅助排查就足够了。我个人的实际体会是pytest fixture 这套机制用得越深入越发现它像一套依赖注入容器只是披着简单装饰器的外壳。真正的高手写测试代码不是看单个 fixture 写得多华丽而是看整个测试套件的 fixture 组织是否清晰、scope 是否克制、autouse 是否克制。很多测试项目后期维护困难最大的原因就是 fixture 被滥用、autouse 满天飞导致测试执行逻辑变成一个黑盒。如果你能用一两句话向同事解释清楚每个测试运行前到底会发生什么你的 fixture 设计就是成功的。