pytest中如何根据条件跳过非必要的fixture实例化？

之前写法的性能问题根源 #

pytest的fixture依赖解析是静态前置的：只要把某个fixture写在当前fixture的参数列表里，不管后续分支逻辑是否实际用到这个fixture，pytest都会在执行当前fixture前完成所有参数依赖的实例化。
这就是你哪怕走快速fixture的分支，还是会等满5分钟的核心原因——slow_fixture被硬编码在参数列表里，pytest不管你用不用，先把它初始化完才会往下走你的判断逻辑。

可落地的实现方案 #

借助pytest内置的request上下文对象，把慢fixture的实例化从静态依赖改成运行时动态获取，就能完全解决这个问题：

1. 从everyday_fixture的参数列表里移除slow_fixture，只保留必然要用到的fast_fixture和内置的request对象
2. 把slow_fixture的实例化逻辑放到需要用到它的分支里，通过request.getfixturevalue()手动触发初始化
   对应实现代码：

import pytest

@pytest.fixture()
def everyday_fixture(fast_fixture, request):
    # fast_fixture是判断逻辑的必需项，本身初始化速度快，直接静态注入无额外性能损耗
    if fast_fixture.is_usable():
        yield fast_fixture
    else:
        # 只有执行到这行代码时，pytest才会真正触发slow_fixture的完整初始化流程
        slow_fixture = request.getfixturevalue("slow_fixture")
        yield slow_fixture

关键注意事项 #

• 完全兼容第三方提供的不可修改的slow_fixture：不管是静态参数注入，还是动态通过getfixturevalue获取，pytest对第三方fixture的生命周期管理（包括初始化、作用域匹配、资源teardown）逻辑完全一致，不需要对第三方包做任何改动。
• 动态触发的fixture生命周期和正常使用无差异：如果slow_fixture本身是带yield清理逻辑的，走到else分支初始化后，对应的资源回收、teardown流程会在测试结束时正常执行，不会出现资源泄漏。
• 性能收益符合预期：当fast_fixture可用时，代码完全不会走到获取slow_fixture的分支，5分钟的慢fixture初始化流程会被完全跳过，整体耗时只和快速fixture的初始化耗时挂钩。

内容的提问来源于stack exchange，提问作者Pythonisto