★ FEATURED ARTICLE 1. 为什么是Fixture从重复的代码搬运工到依赖注入1.1 传统测试代码里最让人烦躁的部分很多从 unittest 转过来的测试工程师最初对 pytest 的印象就是“写用例简单不要写类一个函数一个断言”。但真正上手之后才发现测试用例本身只是冰山一角真正折磨人的是每个用例执行前后那堆又臭又长的准备和清理代码。我之前维护过一个订单服务项目测试目录里到处是这样的代码class TestOrderAPI(unittest.TestCase): def setUp(self): self.db create_memory_db() self.db.migrate() self.client HttpClient() self.client.login(admin, test-token) self.user create_test_user(self.db) def tearDown(self): self.client.logout() self.db.drop_all()单看这个类还勉强能忍但如果同仓库里有十几个测试类每个类都自己维护一套“建立数据库、迁移、登录、创建测试用户”的流程后果就是准备逻辑严重重复改一个表结构要改十几个地方测试类之间没法共享公共状态要么全部重新初始化要么把初始化逻辑全塞到模块顶层的公共函数里最后变成一坨无法定位归属的“工具代码”作用域控制全靠手工。想在“整个测试过程只登录一次”和“每条用例都重新登录”之间切换要改的代码远不止一行一旦某个清理步骤抛异常tearDown 链断裂脏数据留在库里后续用例全部红灯而且报错的根本不是真正有问题的功能代码。这些痛点在中小型项目里还可以靠“人工纪律”硬撑比如约定每个人都要把数据库初始化写在 setUp 里。但只要团队超过三个人测试代码就会迅速退化成让人不想碰的遗留物。1.2 Fixture 对这件事的解法让测试函数“声明需求”而不是“实现准备”pytest 的 fixture 机制和传统的 setUp/tearDown 有本质区别。它不要求你把初始化代码放在某个固定的钩子函数里而是让你单独定义一个可以被任意测试函数“按需注入”的资源。看一段很典型的代码import pytest import requests pytest.fixture def api_client(): client ApiClient() client.login(admin, test-token) yield client client.logout() def test_create_order(api_client): order api_client.post(/orders, {...}) assert order.status_code 201这里的关键不在“少写了几行代码”而在于控制流反转了。test_create_order 这个函数只需要在参数列表里声明自己需要 api_clientpytest 就会在收集阶段通过函数签名发现这个依赖运行时自动寻找同名的 fixture 函数执行它把返回值传入测试函数等测试函数结束后再继续执行清理逻辑。我用一个生活化的类比来解释这件事。传统的写法相当于顾客进餐厅后自己跑进后厨开火、洗菜、炒菜吃完还要自己刷碗。某天你换了菜单后厨的锅灶全都得自己跟着重学。而 fixture 的写法是顾客坐在餐桌边说一句“我要一碗面向后端”厨房自动开火下面端上来等你吃完把碗收走。测试函数只需要关心“这碗面好不好吃”不需要关心“面条是哪锅水煮的碗谁来刷”。这种设计带来的直接收益有三个资源准备和清理逻辑从测试函数里完全剥离同一个 fixture 可以被几十个测试函数复用fixture 可以互相依赖。比如数据库连接 fixture 可以被“创建用户数据”的 fixture 复用而业务接口测试的 fixture 又依赖“创建用户数据”形成一条清晰的依赖链执行顺序不再靠人肉保证。pytest 根据依赖关系自动推算出 fixture 的启动和销毁顺序清理顺序严格按照“后建的先拆”原则执行不会出现数据库连接还没关就开始删表之类的低级错误。2. Fixture 的声明周期管理作用域、yield 与内置神器2.1 用表格看透五种作用域用 fixture 一段时间后你会遇到一个新的困惑一个 fixture 到底应该在什么时候创建、什么时候销毁pytest 给出了五个作用域选项我用项目里实际遇到的场景来逐条说。作用域刷新时机典型使用场景function每个测试函数执行前后各一次临时数据、独立状态的配置默认值class同一个测试类的所有用例共享需要初始化一次类级别的完整流程module同一个模块内所有用例共享模拟数据库表结构、公共 HTTP 客户端package同一个包的测试共享包级环境变量、共享缓存目录session整个测试会话只创建一次第三方服务连接、结果报告汇总默认作用域是 function这意味着每一条用例都会重新执行一遍 fixture。这个默认值很安全因为它隔离了测试之间的状态污染。但它的代价是慢。如果你有 500 条订单接口测试每条用例都重新建一次内存数据库、重新迁移、重新灌基础数据整个过程可能要多跑十几分钟。所以在我的项目里最常见的调优就是把迁移和基础数据准备这类“只读固定成本”放到 module 作用域pytest.fixture(scopemodule) def db_engine(): engine create_sqlalchemy_engine(sqlite:///:memory:) run_migrations(engine) seed_base_data(engine) return engine需要注意的是module 作用域并非没有代价。如果你在测试过程中修改了数据下一条用例看到的仍然是同一个被污染的状态。这种场景下我会保留 function 作用域的创建用户、创建订单这类数据类 fixture确保用例之间不互相影响只有“创建引擎、建表结构”这类天然只读的资源才使用 module 或 session 作用域。2.2 yield 与清理异常情况下依然可靠早期我见过一些测试框架的使用者会把清理逻辑放在测试函数本身的 finally 块里或者在 fixture 的尾部直接执行清理代码而不使用 yield。这两种做法在正常流程下没问题但遇到断言失败时就不一定了。pytest 的 fixture 通过 yield 把函数切分成两部分yield 之前是资源准备yield 之后是资源清理。哪怕是测试函数内部发生了 AssertionError、异常退出yield 之后的清理代码也会被执行因为 pytest 在运行时把它放进了类似 finally 的管理机制里。一个比较完整的写法pytest.fixture def temp_mailbox(): mailbox MailBox() mailbox.start() yield mailbox mailbox.stop() cleanup_mailbox_directory(mailbox.path)我习惯在 yield 之前的准备阶段尽量用上下文管理器或 try/except 包裹避免“准备到一半就失败但清理也没执行”。另外还要注意 yield 前后的代码不一定只能写一次比如这样也是合法且有用的pytest.fixture def two_stage_resource(): stage_one StageOne() stage_one.init() yield stage_one stage_one.close() stage_two StageTwo(stage_one) stage_two.start() yield stage_two stage_two.stop()这个场景相当少见但在某些需要“先拿到第一层连接再根据连接创建第二层资源”的复合场景里yield 两次可以把两层资源的生命周期都纳入 pytest 的保护范围。2.3 三个开箱即用的内置 Fixture很多刚接触 pytest 的读者会误以为 fixture 必须写在 conftest.py 里自己定义才算完整。但 pytest 内置了一些高频 fixture几乎每个项目都用得上。第一个是 tmp_path。它会在每次测试执行时创建一个独立临时目录并在测试结束时自动清理。对于需要写文件、导出报表、保存上传文件的测试来说直接用 tmp_path 比在代码里手工生成随机目录要安全得多def test_export_service_writes_report(tmp_path): export_path tmp_path / report.csv export_service.export(export_path) assert export_path.exists()第二个是 capsys。它专门捕获 stdout 和 stderr 输出。想测试命令行工具的日志输出、或者验证某个函数有没有打印正确的提示信息直接让测试函数接收 capsys 参数用 capsys.readouterr() 读取即可def test_cli_prints_success(capsys): run_cli([--deploy]) captured capsys.readouterr() assert Deployed in captured.out第三个是 monkeypatch。它用来在测试中动态替换属性或者环境变量并且会在测试结束后自动还原。早期我经常手动记录原值然后手工恢复各种漏恢复的 bug 层出不穷。现在统一改用 monkeypatch 之后再也没见过测试环境污染def test_config_reads_env(monkeypatch): monkeypatch.setenv(APP_MODE, staging) assert get_config().mode staging这三个内置 fixture 的共同优势是你不需要声明 scope它们的管理机制已经内置好更重要的是它们的清理逻辑不会因为你测试失败而跳过。3. 高级玩法参数化、组合与工厂型 Fixture3.1 参数化 Fixture一份逻辑测多组数据有经验的测试工程师都知道最怕的是“一条用例只验证了一种情况”。用户登录接口要是只测正确密码等于没测。常规做法是每条用例写一个独立函数或者在一个函数里写循环。但循环有个问题如果第三种输入失败了你很难一眼看出是循环的第几轮出了问题而且失败后的行为往往不够透明。pytest.fixture 支持 params 参数一个 fixture 可以声明为多组参数的集合。pytest 会为每一组参数执行一次测试函数pytest.fixture(params[ {username: valid_user, password: right_pass, expect: 200}, {username: valid_user, password: wrong_pass, expect: 401}, {username: invalid_user, password: right_pass, expect: 404}, ]) def login_case(request): return request.param def test_login(login_case): resp api.login(login_case[username], login_case[password]) assert resp.status_code login_case[expect]这里要重点理解的是 request.param 的作用。pytest 在运行参数化 fixture 时会把当前参数传给 fixture 函数而 fixture 函数的第一个参数 request 就是这个运行上下文的载体。它不仅包含 param还包含当前测试节点的名称、所在文件路径、索引等信息在排查问题时非常好用。这种参数化方式比函数内循环好在哪最直接的体验是失败报告极其清晰。测试报告会分别列出 3 个子用例哪一组数据失败控制台会精确指向哪一组你不需要自己推测是第三轮还是第四轮出了错。而且每一组 fixture 的创建和销毁是相互隔离的不会因为上一组数据污染了资源而影响下一组。3.2 组合 Fixture像搭积木一样组装依赖当一个测试需要数据库、已登录用户、一个空购物车同时存在时很多人的第一反应是写一个“超级 fixture”把所有准备逻辑塞进去。这个思路要克制因为超级 fixture 会变成新的代码灾难它同时承担了太多职责任何一个环节改动所有相关测试都会受影响。正确做法是让 fixture 保持小而专一再通过组合把它们串起来pytest.fixture def db_session(db_engine): session create_session(db_engine) yield session session.close() pytest.fixture def current_user(db_session): user create_user(db_session, nametester) return user pytest.fixture def cart_for_user(current_user): cart create_cart(current_user) return cart def test_checkout(db_session, cart_for_user): result checkout(db_session, cart_for_user.id) assert result.is_received这个链条很清晰test_checkout 依赖两个资源其中一个又依赖另一个另一个再依赖下一个。pytest 自动完成传递依赖解析。如果某天你换了数据库连接方式只需要改 db_engine 一个 fixture而 current_user、cart_for_user 这些高层 fixture 一个都不用动。这就是组合带来的可维护性收益。不过组合也有组合的讲究。我在项目里发现一个规律fixture 的依赖深度超过四层之后读代码的人就需要在多个文件之间来回跳转。这时候我倾向于把“业务数据准备”相关的链条收拢到一个偏高层级的 fixture 里保留三层左右的抽象而不是无限拆分。3.3 工厂模式让同一份资源开出不同结果常规 fixture 返回的是一个固定对象。但有些场景下你需要在外层动态控制这个对象的状态。比如“创建一个订单”这个 fixture如果固定返回一个订单对象那么所有依赖于它的测试只能拿到“同一个用户、同一个商品、同一个金额”的订单这显然限制了测试场景。这时候可以用工厂模式让 fixture 返回一个可以接收参数的函数pytest.fixture def make_order(db_session): def _make_order(userNone, amount100, statuspending): user user or create_default_user(db_session) order Order(user_iduser.id, amountamount, statusstatus) db_session.add(order) db_session.commit() return order return _make_order def test_cancel_pending_order(make_order): order make_order(statuspending) assert order.can_cancel is True def test_cancel_paid_order(make_order): order make_order(amount299, statuspaid) assert order.can_cancel is False表面上看这只是包装了一层函数。但实际价值在于调用方可以按需定制订单数据而无需复制任何初始化逻辑。这种工厂 fixture 在接口测试、业务规则测试中非常常用也是我向所有从单元测试转过来的同事强烈推荐的一种模式。工厂 fixture 唯一的注意事项是内部闭包函数尽量不要执行太重的资源创建。如果每一次 make_order 调用都要重新连一次数据库这个循环就比较难看了。更好的做法是工厂内部依赖那些已经处于低开销状态的 session 或者 connection fixture让工厂本身只负责数据组装。4. conftest.py 与项目结构让Fixture在正确的范围内生效4.1 conftest 是 Fixture 的“分集水器”pytest 有一个独特的设计conftest.py 文件里的 fixture 并不是从文件顶部向下流式定义的而是按照目录层级生效。也就是说放在根目录 conftest.py 里的 fixture可以被整个测试套件任意引用放在某个子目录 conftest.py 里的 fixture只对这个子目录下所有测试文件生效。这个机制非常像小区的变电箱。根目录的 conftest 相当于总闸给整个小区供电每个楼的 conftest 相当于楼层配电箱控制本楼用电而测试函数里的 fixture 就像房间里的插座按需取电。我一般会这样组织tests/ conftest.py # 全局共用的 db_engine、api_client feature_a/ conftest.py # 只属于 feature_a 的 mock_server test_a1.py test_a2.py feature_b/ conftest.py # 只属于 feature_b 的文件系统 fixture test_b1.py这种分级方式最大的好处是你在修改某个 fixture 时能清晰判断影响范围。改根目录 conftest.py 里的 api_client全项目所有测试都可能受影响只改 feature_a/conftest.py 里的 mock_server那影响范围就只限于 feature_a。有一个细节需要提醒pytest 搜索 fixture 时scope 是在定义处决定的而不是在使用处。一个在根目录定义为 session 作用域的 fixture即使只被 feature_a 下的两条用例使用它也仍然会在整个测试会话中保持一份实例。所以不要因为“只在一个地方用”就把所有东西放在 session 作用域作用域的评估范围要放全局来看。4.2 autouse能不用就尽量别用autouse 是 pytest 提供的一个开关设置为 True 的 fixture 不需要测试函数显式声明也会自动执行。这个机制听起来很省事尤其适合“每个用例前都备份一次数据库”“每个用例后都清理临时文件”这类横切逻辑。但因为 autouse 不可见它也是我见过最容易埋雷的机制之一。说三件我在真实项目中踩过的坑第一不可见导致排查困难。一个测试失败当你逐行查看这个测试函数时根本看不到它依赖哪些 autouse fixture你只会在运行日志里看到“多出来”的初始化动作排查成本直线上升。第二autouse 和 scope 叠加时执行顺序容易让人迷糊。一个 session 级别的 autouse fixture 会在整个测试套件启动时就执行连哪些测试文件会被运行都不知道如果它去读取某个动态生成的配置文件大概率会扑空。第三多个 autouse fixture 之间存在隐式顺序依赖时几乎无法通过代码读出来。pytest 默认按照 fixture 的依赖关系排序但如果两个 autouse 没有显式依赖排序就不那么可控。所以我现在的原则很简单除非某个清理或准备动作确实需要横跨所有用例比如统一设置环境变量、统一收集测试产物否则不要用 autouse。想让大家看到依赖就直接在测试函数参数上写出来。显式 隐式这条原则在测试代码里尤其重要。4.3 同名字 fixture 的覆盖与优先级实际项目中不可避免会遇到 fixture 重名的情况。比如根目录 conftest 定义了一个 databasefeature_a 也需要一个名字相同的 database但实现方式完全不同。pytest 的处理规则是就近取用。简单说测试文件所在目录的 conftest 优先级最高逐级向上找最后是插件和系统级。这个规则符合直觉但有一个容易忽略的坑如果你在 feature_a/conftest.py 里定义了一个新的 database fixture那么 feature_a 里所有依赖 database 的测试都会自动改用新的实现包括那些从根目录继承的其他 fixture——只要它们在内部也依赖 database就会跟着变化。这通常是你想要的但有时候也是不想要的。我的建议是覆盖同名字 fixture 之前先想想是不是应该起一个更明确的名称。比如把数据库 fixture 分开命名为 master_database、feature_database不容易出问题。如果确实需要覆盖尽量把覆盖对象限定在原始定义的下层目录模块中避免跨级覆盖造成全体默认。5. 实战经验排序、排查与性能权衡5.1 用 --setup-show 看清执行顺序测试很难写时我第一个建议永远是加参数运行一次pytest --setup-show。它会很直白地把所有 fixture 的 setup 和 teardown 执行流程打印出来一条条展示在控制台。我自己排查过一次非常诡异的顺序问题。某个测试模块里A fixture 准备了一批种子数据B fixture 准备了一个客户端但每次运行结果都不稳定。打开 --setup-show 后才发现B 在 A 之前执行了因为 B 的依赖和 A 没有显式关联而 A 内部又调用了需要 B 准备的环境。这也再次印证了那条建议不要依赖 fixture 的定义顺序要让依赖关系显式化。另外还有一条调试命令:--fixtures。它会在控制台列出当前测试目录下所有可用的 fixture包括来自 conftest、内置插件以及三方库的。当你看到 pytest 报“fixture not found”时不要急着到处找定义先跑一下这条命令看看这个名字下的可用性与实际定义位置。5.2 排查 Fixture 异常时的四条路径我自己把 fixture 异常排查整理成了一张清单遇到问题直接按顺序过一遍。现象常见原因排查建议fixture not found名称拼写不一致fixture 定义在非 conftest 的普通文件中但未被导入先执行 pytest --fixtures查看搜到的名单fixture 执行后的资源没被清理在 yield 之后抛了异常或者 fixture 本身没有使用 yield将清理逻辑前移或用 finally 保护测试之间互相污染一个 function 作用域资源被 session 作用域资源缓存了状态检查是否有可变对象被多个测试共享执行顺序不稳定fixture 之间没有显式依赖清理阶段顺序错乱添加显式依赖或把共享资源合并成一个 fixture这条清单没有覆盖所有情况但它能解决我在真实项目里遇到的九成问题。尤其“资源没被清理”这一条经常是写 fixture 时习惯性把清理逻辑放在 return 之前导致的。如果用 yield 而不是 return清理逻辑会被 pytest 视为 fixture 的一部分执行时机也就有保障了。5.3 性能优先还是状态隔离优先最后聊一个所有历史项目中都会遇到的问题测试跑得越来越慢怎么办我的第一反应永远是先看 fixture 定义。慢往往是大量 function 作用域 fixture 不断重建造成的。比如有一个读取动态配置文件的 fixture本来把它设为 session 作用域完全可以因为配置在测试期间根本不变但早期把它写成 function 作用域结果是每一条用例都重复读文件跑 2000 条用例就是 2000 次磁盘 IO。优化思路一般是从低到高调整作用域。低风险的一批是不依赖测试函数参数、不依赖临时数据的 fixture比如数据库引擎、配置对象、连接池、第三方客户端。这些天然是只读或可重入的直接改成 session 或 module 作用域性能提升非常明显。但有一条要守住涉及可变数据的 fixture比如“当前登录用户”“当前购物车”千万不能盲目提级。一旦提升作用域后一条用例看到的数据可能还是前一条的遗留状态等你能察觉的时候已经污染了一段时间的测试结果。如果项目里同时存在“整体初始化慢”和“数据隔离要求高”这两种诉求我通常的做法是把慢的重资源用 session 或 module 作用域建好数据类 fixture 继续用 function 作用域但在数据准备里面复用重资源连接而不是重新创建资源。这样既能控制总耗时也不会牺牲测试间的隔离性。6. 写在最后的一些个人体会接触 pytest 的 fixture 越久我越觉得它值得认真对待的关键点不是语法本身而是它背后那套“声明式组织依赖”的思路。测试代码也是代码它同样需要被阅读、被维护、被演进。把数据准备、环境初始化和清理逻辑从测试函数里拆出去让每个 fixture 只负责单一职责再通过作用域和组合把它们串起来整个测试工程就会从“一团乱麻”变成“一张清晰的地图”。我个人的切身体会是与其在写完测试后再回头优化 fixture不如在第一个用例前就认真想清楚哪些资源是全局共享的哪些是每个用例独立的哪些是可以参数化的哪些是应该提升作用域的。做一个简单的 haha 设计草图后面能少改很多代码。另外有一个小技巧用 fixture 写过之后再回头读别人的 pytest 测试代码时先别急着看测试函数体先看测试函数签名的参数列表。参数就是依赖关系的索引这个索引读清楚了整个测试的真实意图也就清楚了。如果你也是从 unittest 迁移过来或者正在被重复的 setup 代码折磨我建议下一个项目就直接用 fixture 组织所有测试资源。踩过几个坑之后你会意识到测试代码优雅与否其实和业务代码一样是设计出来的而不是调试出来的。
阅读完成 · 觉得有帮助？
