pytest 合集写到第六篇终于该聊 fixture 了。前面几篇讲断言、讲参数化、讲用例组织的时候fixture 都是被我一带而过的角色但说实话它才是 pytest 真正区别于 unittest 的那块地基。我最早写自动化的时候用 unittest 那套 setUp/tearDown每个模块开头先登录一次、每条用例结束再清一次数据几百条用例跑下来光登录耗时就能占掉一半。切到 pytest 之后最直接的感受不是写法变短了而是依赖终于被显式声明出来了——你在用例函数的参数里写了什么它就得从哪来一目了然。fixture 说白了就是一套依赖注入机制函数上打一个pytest.fixture装饰器它就变成一份可被索取的资源用例的参数名写什么pytest 就去找同名的 fixture执行完把返回值塞进来。用它你能统一管理数据库连接、登录态、测试数据、临时目录这些横切关注点也能把准备动作和清理动作写在同一段代码里不用再担心某条用例中途抛异常、teardown 被跳过。这篇适合两类人一类是刚上手 pytest、用例还停留在一个文件一个函数阶段的同学另一类是已经写了一阵子却被作用域冲突、conftest 找不到、并发下数据串号这些问题折磨过的同行。我会从最朴素的痛点讲起把作用域、依赖、生命周期这些机制拆开再给一套我自己在接口自动化项目里跑了两年多的 fixture 体系最后把踩过的坑整理成速查表。1. 我为什么把 fixture 当成 pytest 的分水岭1.1 从 unittest 的 setUp 和 tearDown 说起unittest 的世界里准备和清理是位置绑定的setUp在每条用例前跑tearDown在每条用例后跑setUpClass/tearDownClass绑定到类setUpModule/tearDownModule绑定到模块。这套设计没有错问题是它只能按层级来不能按需求来。比如同一个模块里三条用例要连数据库两条用例只做纯逻辑校验你只能在setUp里判断如果这次不需要数据库就跳过或者干脆拆成两个测试类。久而久之测试类越拆越碎公共逻辑反而到处复制。更麻烦的是数据传递。setUp里创建的 client 对象要传给用例只能挂成self.client用例里到处self.xxx满天飞。如果哪天要把这个 client 换成另一套实现你得把所有self.client的调用点翻一遍。清理逻辑也一样tearDown里写五步清理中间第二步抛异常后面三步就默默不执行了日志里只留一个失败残留数据却在环境里躺着。fixture 把这两个问题一起解决了准备逻辑可以按谁需要谁声明来组合数据通过函数参数传递而不是隐式挂载清理逻辑用yield或addfinalizer保证一定被执行。我第一次看懂yield版 fixture 的时候感觉就像把 setUp 和 tearDown 从两个遥远的函数里搬回了同一个函数体中间只隔一个 yield读起来是人话。1.2 fixture 到底比传统写法强在哪我总结下来是四点。第一是显式依赖用例需要什么参数里写着不需要翻父类、翻装饰器、翻全局变量。第二是可组合一个 fixture 可以请求另一个 fixture像搭积木一样把登录、连接、数据准备串起来pytest 会自动按依赖顺序执行你不用自己排顺序。第三是作用域可调同一条 session 级连接可以在几百条用例间复用而每条用例的数据又能各自独立这是 unittest 层级机制很难优雅做到的。第四是缓存机制同一个作用域内同名 fixture 只会执行一次即使十个用例都请求它底层也只跑一遍。这四点里缓存是最容易被忽略、收益却最大的。我做过一次统计一个接口自动化项目里把登录从 function 级提到 session 级整个回归套件的耗时从 11 分钟降到 6 分钟出头实际改动就是给 fixture 加了个scopesession。1.3 一张表看清 fixture 的能力边界别把 fixture 当万能药它擅长的和不擅长的要分开看。下面这张表是我在团队内部分享时整理的直接照抄过来场景适合用 fixture更合适的替代方案数据库连接、HTTP 会话复用是scope 提到 session—测试数据构造是配合工厂模式复杂数据用 factory-boy 等库环境变量临时修改是配 monkeypatch直接改 .env 容易污染断言辅助工具可以但没必要封装成普通函数更直观跨项目的公共逻辑用 conftest 或独立插件包直接 import 也行看耦合度参数化数据源用params参数用例维度参数化用 parametrize报告中展示步骤不适合用日志或报告库的步骤接口提示fixture 的本质是资源提供者不是万能工具函数。如果你写出来的 fixture 里没有 setup/teardown 语义、也没有被多个用例复用那它十有八九应该是个普通函数。2. 核心机制作用域、依赖与生命周期2.1 五种 scope 的取舍逻辑pytest.fixture(scope...)支持五个取值默认是function。它们决定了 fixture 执行几次、何时清理也决定了它能被谁请求——高作用域不能请求低作用域这是硬规则。scope执行时机典型用途清理时机function每条用例前测试数据、临时目录用例结束后立即清理class每个测试类前类内共享的上下文类内全部用例跑完module每个模块前模块级配置加载模块内用例跑完package每个包前包级子目录共享资源包内用例跑完session整个会话前登录态、数据库连接池全部用例跑完怎么选我的原则是在保证数据隔离的前提下尽量往高作用域提。判断依据是这份资源有没有状态污染风险。登录 token 没有污染风险提到 session数据库连接对象只要没事务悬挂提到 session某个用例专属的 mock 数据一定留在 function随机生成的订单号必须留在 function否则并行跑的时候两条用例会抢同一个订单。这里还有个隐蔽的坑高作用域 fixture 是被缓存的但它请求的低作用域 fixture 会被提级执行。换句话说如果你写了一个 session 级 fixture 请求了 function 级的tmp_pathpytest 会直接抛ScopeMismatch而不是自动帮你降级。这个报错第一次见会懵后面我会专门讲。2.2 fixture 之间的依赖与查找顺序fixture 请求 fixture 的写法极其自然就是把依赖名写进自己的参数里import pytest pytest.fixture(scopesession) def config(): return {base_url: https://api.example.com, timeout: 5} pytest.fixture(scopesession) def api_session(config): import requests session requests.Session() session.headers.update({X-Env: staging}) session.base_url config[base_url] session.timeout config[timeout] yield session session.close()pytest 会自己拓扑排序先config再api_session。清理顺序刚好相反后进先出所以你不用操心关连接的时候配置已经被销毁了这种问题。查找顺序也值得记一下。用例请求一个名字叫db的 fixturepytest 是按从近到远找的当前测试文件 → 同目录及上层的conftest.py就近优先→ 安装的插件里注册的 fixture。所以同一个项目里子目录的 conftest 可以覆盖根目录的同名 fixture这是非常有用的分层手段后面讲目录结构时我会展开。想看清实际执行顺序两个命令必须记住# 打印每条用例用到的 fixture 及其 setup/teardown 时机 pytest --setup-show tests/test_order.py # 只看计划不真跑用来审查依赖树 pytest --setup-plan tests/test_order.py -q我第一次用--setup-show排查为什么这个 fixture 被执行了三次的时候输出里一目了然比在代码里插 print 高效太多。2.3 yield、addfinalizer 与清理逻辑清理逻辑有两种写法。主流是yieldpytest.fixture def temp_user(db): user db.create_user(nameauto_tmp) yield user db.delete_user(user.id)yield 之前的代码是 setupyield 出来的值是用例拿到的值yield 之后是 teardown。哪怕用例里assert失败抛了异常yield 之后的代码照样执行因为 pytest 把 fixture 的收尾交给了自己的 finalizer 机制而不是简单的 try/finally 嵌套。另一种是request.addfinalizer写法啰嗦但更灵活pytest.fixture def multi_step_cleanup(): resources [] def _cleanup(): for item in reversed(resources): item.close() request.addfinalizer(_cleanup) return resources它的优势在于你可以在 fixture 执行过程中动态追加清理动作而且多个 finalizer 会按注册顺序的逆序执行。什么时候用当清理步骤数量不确定、需要在运行时决定时。日常 90% 的场景用 yield 就够了别为了炫技把简单的事写复杂。注意yield 版 fixture 里不要在 yield 之后写会被异常吞掉的逻辑。如果 teardown 自己抛异常pytest 会把这个异常报出来但用例的原始失败信息可能被挤到次要位置排查时容易看错主次。2.4 autouse 用得好是神器用不好是灾难autouseTrue让 fixture 不需要被参数显式请求就自动生效。典型正面用法是全局日志、全局异常兜底、环境校验pytest.fixture(autouseTrue, scopesession) def check_env(): import os assert os.getenv(TEST_ENV), 缺少 TEST_ENV 环境变量拒绝开跑反面用法是把它当成全局变量初始化器。我接手过一个项目根 conftest 里有个autouseTrue的 function 级 fixture每条用例都往数据库塞一条基准数据再在 teardown 里删掉。看起来干净实际跑起来性能极差而且那条数据和一个 session 级的缓存对象产生了隐式的状态耦合导致单跑某条用例必过、全量跑必挂。后来改成需要的人显式请求问题当场消失。我的建议是autouseTrue只用在不生效就没法继续跑的兜底场景例如环境校验、日志初始化、随机种子固定。凡是涉及业务数据的一律显式请求。3. 实操从零搭一套能扛住百条用例的 fixture 体系3.1 目录结构与 conftest.py 的分层策略conftest.py是 pytest 的插件式配置文件pytest 会自动发现并加载它不需要 import。它最大的价值是分层根目录放全局资源子目录放该业务域的专属资源。project/ ├── conftest.py # session 级配置、日志、登录态 ├── pytest.ini ├── tests/ │ ├── conftest.py # 全局数据清理、公共校验 │ ├── order/ │ │ ├── conftest.py # 订单域专属 fixture │ │ ── test_order_create.py │ └── user/ │ ├── conftest.py # 用户域专属 fixture │ ── test_user_profile.py └── utils/ └── client.py分层带来的一个实际好处是覆盖能力。假设根 conftest 里有个dbfixture 连的是测试库tests/order/下你想让它连影子库直接在同目录 conftest 里重新定义一个同名 fixture 即可作用范围仅限于该目录。这个机制比环境变量开关优雅得多因为它把差异写在了需要差异的地方。有一点必须提醒conftest.py不能被普通模块 import你应该把它当成配置入口而不是工具模块。公共函数请单独放 utils 目录否则一旦被 importpytest 会认为你在做重复加载容易出现难以解释的行为。3.2 接口自动化实战token 复用与数据隔离下面这套结构是我目前在维护的接口自动化项目的简化版跑了两年多几百条用例规模实践下来比较稳。第一层session 级登录。整个会话只登录一次token 存在 fixture 返回值里import os import pytest import requests pytest.fixture(scopesession) def api_base(): return os.getenv(API_BASE, https://api.example.com) pytest.fixture(scopesession) def token(api_base): resp requests.post( f{api_base}/login, json{username: os.getenv(API_USER), password: os.getenv(API_PASS)}, timeout10, ) resp.raise_for_status() return resp.json()[data][token] pytest.fixture(scopesession) def api_client(api_base, token): session requests.Session() session.headers.update({Authorization: fBearer {token}}) session.base_url api_base yield session session.close()第二层function 级数据隔离。每条用例创建自己的订单用完即删pytest.fixture def created_order(api_client): resp api_client.post(/orders, json{sku: SKU-001, qty: 1}) order_id resp.json()[data][id] yield order_id api_client.delete(f/orders/{order_id})这套结构的关键点是有状态的东西永远留在 function 作用域无状态或只读的东西尽量往上提。token 是只读字符串可以 session订单是会变状态的对象必须 function。很多团队把订单也提到 session 想省时间结果就是用例之间互相干扰排查成本远高于省下的那几秒。3.3 参数化 fixture一套用例跑多套环境pytest.fixture(params[...])让 fixture 带上参数pytest 会为每个参数值各跑一遍用到它的用例用例 ID 也能自定义pytest.fixture(params[dev, staging], ids[env-dev, env-staging]) def env_config(request): mapping { dev: {base: https://dev-api.example.com, retry: 1}, staging: {base: https://stg-api.example.com, retry: 3}, } return mapping[request.param]用例里只要写def test_health(env_config)这条用例就会被自动展开成两条报告里显示为test_health[env-dev]和test_health[env-staging]。这个能力特别适合灰度验证、多租户兼容性检查这类同一逻辑、不同入口参数的需求。不过要留意组合爆炸。如果一个用例同时依赖两个参数化 fixture各自有 3 个和 4 个参数值那这条用例会被展开成 12 条。我一般在 review 时会特意数一下参数化组合数超过 10 条就考虑拆用例或者换用 parametrize。3.4 fixture 与 parametrize 组合的两种写法对比同一个需求——用不同的用户角色调同一个接口——有两种实现路径效果差别很大。写法一用参数化 fixturepytest.fixture(params[admin, guest]) def role_token(request, api_client): resp api_client.post(/login, json{role: request.param}) return resp.json()[data][token] def test_permission(role_token, api_client): resp api_client.get(/admin/panel, headers{Authorization: fBearer {role_token}}) assert resp.status_code in (200, 403)写法二用indirectTrue把 parametrize 的值透传给 fixturepytest.fixture def role_token(request, api_client): resp api_client.post(/login, json{role: request.param}) return resp.json()[data][token] pytest.mark.parametrize(role_token, [admin, guest], indirectTrue) def test_permission(role_token, api_client): resp api_client.get(/admin/panel, headers{Authorization: fBearer {role_token}}) assert resp.status_code in (200, 403)两者跑出来的用例 ID 差不多区别在于控制权在谁手里。写法一把有哪些角色写死在 fixture 里全项目所有依赖它的用例都跟着展开改一次影响一片写法二把参数值放在用例上粒度更细不同用例可以用不同的角色集合。我现在的习惯是参数集合全局统一比如所有环境用参数化 fixture参数集合因用例而异比如角色、状态码就用indirectTrue。3.5 pytest.ini 里和 fixture 相关的配置项配置文件不大但几个和 fixture 相关的项值得单独说[pytest] testpaths tests addopts -v -ra --strict-markers markers slow: 标记耗时用例 smoke: 冒烟用例集--strict-markers虽然不是 fixture 专属但它能拦住那些随手写的自定义 marker避免团队里出现一堆没人认识的标签。至于 fixture如果你希望某个 fixture 在所有用例里都生效别去 ini 里找全局开关——pytest 没有这种配置正确做法是在包级 conftest 里用autouseTrue或者在模块顶部写import pytest pytestmark pytest.mark.usefixtures(reset_tenant)这个usefixtures写法还有一个妙用当 fixture 只负责清理、返回值根本用不上时用它比在函数签名里塞一个用不到的参数更干净。4. 进阶技巧request 对象、工厂模式与内置 fixture4.1 request 对象里我常用的四个属性fixture 函数可以接收一个内置参数request它是一把万能钥匙。我最常用的四个属性分别解决四类问题。request.param用在参数化 fixture 里前面例子已经出现过。request.node能拿到当前用例对象常用来做读取用例上的自定义 marker这类元编程pytest.fixture def retry_times(request): marker request.node.get_closest_marker(retry) return marker.args[0] if marker else 0request.cls在类作用域 fixture 里指向当前测试类适合往类上挂共享属性。request.getfixturevalue(name)是最有意思的一个——它允许 fixture 在运行时按名字动态获取另一个 fixturepytest.fixture def lazy_client(request): env request.getfixturevalue(env_config) if env[retry] 1: return request.getfixturevalue(resilient_client) return request.getfixturevalue(plain_client)这个能力要克制使用。它把静态依赖变成了动态依赖--setup-show看到的依赖树会变得不完整新人接手时容易看不懂。我一般只在依赖太多、大部分场景用不上、全写上会拖慢启动时才用它。4.2 工厂即 fixture解决动态数据生成一条用例要创建三个用户或者创建数量在运行时才确定这是 fixture 最常见的痛点。直接返回一个对象的做法不够用因为每请求一次拿到的是同一个对象作用域内只执行一次。解法是把 fixture 做成工厂——返回一个函数pytest.fixture def make_user(api_client): created [] def _make(roleguest, **overrides): payload {role: role, nickname: auto} payload.update(overrides) resp api_client.post(/users, jsonpayload) resp.raise_for_status() user resp.json()[data] created.append(user[id]) return user yield _make for uid in created: api_client.delete(f/users/{uid})用例里怎么写def test_batch(make_user): u1 make_user(); u2 make_user(roleadmin)。这个模式的价值在于创建几次、造什么数据由用例说了算而清理责任仍然归 fixture 管。这是我个人认为 fixture 最优雅的一个用法比每写一条用例就手写一遍清理逻辑强太多。需要注意清理的幂等性。如果用例中途已经把某个用户删了teardown 再删一次会报 404所以我一般会包一层忽略 404 的处理或者只记录仍然存在的资源。4.3 临时文件与目录tmp_path 的正确用法pytest 内置了几个不用声明就能直接用的 fixture临时目录系列是使用频率最高的。tmp_path是 function 作用域返回一个pathlib.Path对象每条用例拿到的目录都不同跑完自动清理默认保留最近几轮方便排查def test_export_csv(api_client, tmp_path): target tmp_path / export.csv target.write_text(id,name\n1,demo\n, encodingutf-8) resp api_client.post(/files, files{file: target.open(rb)}) assert resp.status_code 200如果要在多条用例之间共享一个目录用 session 级的tmp_path_factorypytest.fixture(scopesession) def fixture_dir(tmp_path_factory): path tmp_path_factory.mktemp(fixtures) (path / sample.json).write_text({ok: true}, encodingutf-8) return path提示老项目里可能见到tmpdir它返回的是旧的 py.path 风格对象pytest 官方推荐新代码统一用tmp_path。两者功能重叠别在同一个项目里混用会让静态检查很难受。4.4 monkeypatch 配合 fixture 做环境隔离monkeypatch也是内置 fixture专治我要临时改点全局东西的需求改环境变量用setenv改对象属性用setattr改字典键用setitem改工作目录用chdir往 sys.path 插路径用syspath_prepend。它最舒服的地方是自动回滚用例结束自动还原不需要你写 finally。def test_feature_toggle(monkeypatch, api_client): monkeypatch.setenv(FEATURE_NEW_PRICING, 1) monkeypatch.setattr(utils.client.RETRY_LIMIT, 0) resp api_client.get(/pricing) assert resp.json()[data][mode] new这里有个坑我踩过setattr的目标必须是字符串路径且被改的对象和使用该对象的地方要是同一个引用。如果你在模块 A 里from x import LIMIT然后想 monkeypatch 模块 A 的LIMIT你得在模块 A 的命名空间里改而不是改x.LIMIT。这个细节在 Python 里很反直觉我第一次遇到的时候盯着断言失败看了半小时。4.5 同名 fixture 的覆盖规则与团队协作约定覆盖规则一句话说清就近优先后定义覆盖先定义。根 conftest 定义了db子目录 conftest 又定义了db那子目录及其下层的用例用的是子目录版本。测试文件内部再定义一次文件内优先。这个机制威力很大但也容易造成为什么两条用例连的库不一样的困惑。我在团队里定过三条约定效果不错。第一条覆盖必须加注释说明差异原因比如# 本目录用例全部依赖影子库与根配置不同。第二条禁止在测试文件里定义 fixture除非它只被这一个文件用到且名字带文件前缀避免误覆盖。第三条公共 fixture 统一放根 conftest在 README 里维护一份清单新同学先读清单再写代码。5. 常见问题与排查技巧实录5.1 报错信息速查表fixture 相关的报错大多长得很像我整理了一张对照表按这张表基本能定位到八九成问题报错关键字常见原因处理方向fixture xxx not found名字拼错、conftest 层级不对、未被发现跑pytest --fixtures确认名字检查文件是否在测试路径内ScopeMismatch高作用域 fixture 请求了低作用域 fixture统一作用域或把依赖拆到更低作用域The requested fixture has no parameter defined用了indirectTrue但 fixture 没读request.param在 fixture 里加request.paramfixture function has already been registered同名 fixture 在多处定义且加载顺序冲突检查是否有重复注册的插件或 import 顺序问题got unexpected keyword argument参数名与 fixture 名不匹配对齐函数签名和 fixture 名finalizer 抛异常teardown 逻辑本身有 bug单独跑一次 teardown 路径加幂等判断pytest --fixtures这个命令我强烈建议加到日常习惯里它会列出当前可见的所有 fixture、来源文件和说明字符串。给 fixture 写 docstring 在这里会直接展示出来等于免费的功能文档。5.2 ScopeMismatch 的三种真实场景与解法第一种session 级 fixture 请求 function 级的tmp_path。解法是改用tmp_path_factory自己mktemp一个目录生命周期跟着 session 走。第二种session 级的客户端请求了 function 级的数据准备 fixture。这通常说明设计想混了数据准备本身就是每条用例独立的不该被 session 级资源依赖。解法是把客户端降级到 function或者把数据准备逻辑内联到用例里。第三种类的setup_method想用 session 级 fixture。类方法不走依赖注入只能用request.cls曲线救国或者干脆把类改成函数式用例。我在实际项目里的做法是尽量避免混用类和 fixture统一函数式风格request.cls只在必须保留类的历史项目里用。还有一种特别隐蔽的fixture 被usefixtures在模块级声明模块级声明的生效范围是模块而 fixture 本身是 session 级。这种情况不报错但模块级 usefixtures 只有在模块有至少一条用例时会触发空模块不会执行排查时容易被为什么这个 fixture 没跑困扰。5.3 并发执行下的 fixture 陷阱并行跑pytest-xdist是提速利器但它和 fixture 有两个必须知道的交互。第一session 级 fixture 是每个 worker 一份不是全局一份。你开了 4 个 worker登录就会执行 4 次数据库连接池也是 4 份。如果你的外部系统对并发登录有风控比如同账号多端登录互踢就得改成每个 worker 用不同账号或者在worker_id上做区分import os import pytest pytest.fixture(scopesession) def worker_tag(worker_id): return f{worker_id}-{os.getpid()}worker_id是 xdist 提供的 fixture非并行模式下值是master用之前记得判断一下否则依赖它的用例在本地单跑时会拿到意外取值。第二默认的分发策略load是按用例均匀分配可能把同一个模块的用例分到不同 worker。如果你的 fixture 在模块级做了资源准备比如往某个目录写文件两边同时跑就会打架。这时改用--dist loadscope让同一模块或同一类的用例落在同一个 worker 上问题自然消解。5.4 我踩过的坑与调试小技巧最后分享几个用血换来的经验。关于调试--setup-show用来确认执行顺序--fixtures -v用来确认可见性-s用来关掉输出捕获看实时日志这三个搭配起来能解决绝大多数它为什么不跑/为什么跑了三次的问题。如果怀疑缓存作怪在 fixture 第一行打印一次id()看是不是同一个对象。关于清理teardown 里所有外部调用都要有超时和异常兜底。我遇到过一次生产事故级的排查teardown 里删数据的请求卡住导致整轮回归在最后十分钟里一直挂起日志看起来像跑完了但没退出。加了timeout5和 try/except 之后即使清理失败也能继续往下走失败信息进日志而不是阻塞流水线。关于命名我给自己定的规则是xxx_client表示长连接类资源make_xxx表示工厂xxx_factory表示批量构造created_xxx表示已创建的具体数据check_xxx/reset_xxx表示纯动作类配合 usefixtures。名字里带上语义比加十行注释都管用。团队里新同学看名字就能猜出这个 fixture 是给值还是干活review 效率高很多。关于迁移如果你手上有一堆 unittest 老用例不必一次性翻新。我的做法是先在最外层加一个 conftest把老用例里重复的 setUp 逻辑抽成 fixture然后一次迁移一个模块。迁移过程中注意setUpClass对应 scopeclasssetUpModule对应 scopemodule一一映射过去行为基本不会变。等所有模块迁完最后统一把 fixture 的作用域往 session 提用一个耗时对比数据来验证收益——我那次是把 11 分钟压到 6 分半也就是在那之后团队里再没人怀念 unittest 的写法了。