当前位置：首页 > news >正文

pytest（1）：fixture从入门到精通

news 2025/9/8 8:20:51

pytest（1）：fixture从入门到精通

- 前言
- 1. Fixture 是什么？为什么我们需要它？
- 2. 快速上手：第一个 Fixture 与基本用法
- 3. 作用域 (Scope)：控制 Fixture 的生命周期
- 4. 资源管理：Setup/Teardown：`yield`
- 5. 参数化 Fixture：让 Fixture 更强大
- 6. 自动使用的 Fixture (`autouse`)：便利性与风险
- 7. Fixture 的组合与依赖：构建复杂的测试场景
- 8. 共享 Fixture：`conftest.py` 的妙用
- 9. 高级技巧与最佳实践
- 10. 常见陷阱与避坑指南
- 总结

前言

大家好！我们今天来学习 Python 测试框架中的最具特色的功能之一：Fixture。

可以说，掌握了 Fixture，你就掌握了 Pytest 的精髓。它不仅能让你的测试代码更简洁、更优雅、更易于维护，还能极大地提升测试的复用性和灵活性。本文将带你系统性地探索 Fixture 的世界，从最基础的概念到高级的应用技巧，灵活地运用 Fixture 并解决实际测试场景中遇到的常见问题。

准备好了吗？让我们开始这场 Fixture 的深度探索之旅！

1. Fixture 是什么？为什么我们需要它？

在软件测试中，我们经常需要在执行测试用例之前进行一些准备工作 (Setup)，并在测试结束后进行一些清理工作 (Teardown)。

Setup 可能包括：
- 创建数据库连接
- 初始化一个类的实例
- 准备测试数据（如创建临时文件、写入注册表、启动模拟服务）
- 登录用户
Teardown 可能包括：
- 关闭数据库连接
- 删除临时文件
- 清理测试数据
- 注销用户

传统的测试框架（如 unittest）通常使用 setUp() 和 tearDown() 方法（或 setUpClass/tearDownClass）来处理这些任务。这种方式虽然可行，但在复杂场景下会遇到一些问题：

代码冗余: 多个测试用例可能需要相同的 Setup/Teardown 逻辑，导致代码重复。
灵活性差: setUp/tearDown 通常与测试类绑定，难以在不同测试文件或模块间共享。
粒度固定: setUp/tearDown 的执行粒度（每个方法或每个类）是固定的，不够灵活。
可读性下降: 当 Setup/Teardown 逻辑变得复杂时，测试方法本身的核心逻辑容易被淹没。

Pytest Fixture 应运而生，目的在于解决这些痛点。

Fixture 本质上是 Pytest 提供的一种机制，用于在测试函数运行之前、之后或期间，执行特定的代码，并能将数据或对象注入到测试函数中。 它们是可重用的、模块化的，并且具有灵活的生命周期管理。

使用 Fixture 的核心优势：

解耦 (Decoupling): 将 Setup/Teardown 逻辑与测试用例本身分离。
复用 (Reusability): 定义一次 Fixture，可在多个测试中重复使用。
依赖注入 (Dependency Injection): 测试函数通过参数声明其依赖的 Fixture，Pytest 自动查找并执行。
灵活性 (Flexibility): 支持多种作用域（生命周期），满足不同场景的需求。
可读性 (Readability): 测试函数专注于测试逻辑，依赖关系清晰可见。
模块化 (Modularity): Fixture 可以相互依赖，构建复杂的测试环境。

理解了 Fixture 的“为什么”，我们就能更好地体会它在实际应用中的价值。接下来，让我们看看如何“动手”。

2. 快速上手：第一个 Fixture 与基本用法

创建一个 Fixture 非常简单，只需要使用 @pytest.fixture 装饰器来标记一个函数即可。

# test_basic_fixture.py
import pytest
import tempfile
import os# 定义一个简单的 Fixture
@pytest.fixture
def temp_file_path():"""创建一个临时文件并返回其路径"""# Setup: 创建临时文件fd, path = tempfile.mkstemp()print(f"\n【Fixture Setup】创建临时文件：{path}")os.close(fd) # 关闭文件描述符，仅保留路径# 将路径提供给测试函数yield path # 注意这里使用了 yield，稍后会详细解释# Teardown: 删除临时文件print(f"\n【Fixture Teardown】删除临时文件：{path}")if os.path.exists(path):os.remove(path)# 测试函数通过参数名 'temp_file_path' 来请求使用这个 Fixture
def test_write_to_temp_file(temp_file_path):"""测试向临时文件写入内容"""print(f"【测试函数】使用临时文件：{temp_file_path}")assert os.path.exists(temp_file_path)with open(temp_file_path, 'w') as f:f.write("你好，Pytest Fixture！")with open(temp_file_path, 'r') as f:content = f.read()assert content == "你好，Pytest Fixture！"def test_temp_file_exists(temp_file_path):"""另一个测试，也使用同一个 Fixture"""print(f"【测试函数】检查文件存在：{temp_file_path}")assert os.path.exists(temp_file_path)

运行测试 (使用 pytest -s -v 可以看到打印信息):

pytest -s -v test_basic_fixture.py

测试结果输出如下：
在这里插入图片描述

关键点解读：

@pytest.fixture 装饰器: 将函数 temp_file_path 标记为一个 Fixture。
依赖注入: 测试函数 test_write_to_temp_file 和 test_temp_file_exists 通过将 Fixture 函数名 temp_file_path 作为参数，声明了对该 Fixture 的依赖。Pytest 会自动查找并执行这个 Fixture。
执行流程:
- 当 Pytest 准备执行 test_write_to_temp_file 时，它发现需要 temp_file_path 这个 Fixture。
- Pytest 执行 temp_file_path 函数，直到 yield path 语句。
- yield 语句将 path 的值（临时文件路径）“提供”给测试函数 test_write_to_temp_file 作为参数。
- 测试函数 test_write_to_temp_file 执行。
- 测试函数执行完毕后，Pytest 回到 temp_file_path 函数，执行 yield 语句之后的代码（Teardown 部分）。
独立执行: 注意，对于 test_write_to_temp_file 和 test_temp_file_exists 这两个测试，temp_file_path Fixture 都被独立执行了一次（创建和删除了不同的临时文件）。这是因为默认的作用域是 function。

这个简单的例子展示了 Fixture 的基本工作方式：定义、注入和自动执行 Setup/Teardown。

3. 作用域 (Scope)：控制 Fixture 的生命周期

默认情况下，Fixture 的作用域是 function，意味着每个使用该 Fixture 的测试函数都会触发 Fixture 的完整执行（Setup -> yield -> Teardown）。但在很多情况下，我们希望 Fixture 的 Setup/Teardown 只执行一次，供多个测试函数共享，以提高效率（例如，昂贵的数据库连接、Web Driver 启动）。

Pytest 提供了多种作用域来控制 Fixture 的生命周期：

function (默认): 每个测试函数执行一次。
class: 每个测试类执行一次，该类中所有方法共享同一个 Fixture 实例。
module: 每个模块（.py 文件）执行一次，该模块中所有测试函数/方法共享。
package: 每个包执行一次（实验性，需要配置）。通常在包的 __init__.py 同级 conftest.py 中定义。
session: 整个测试会话（一次 pytest 命令的运行）执行一次，所有测试共享。

通过在 @pytest.fixture 装饰器中指定 scope 参数来设置作用域：

import pytest
import time# Session 作用域：整个测试会话只执行一次 Setup/Teardown
@pytest.fixture(scope="session")
def expensive_resource():print("\n【Session Fixture Setup】正在初始化...")# 模拟初始化操作time.sleep(1)resource_data = {"id": time.time(), "status": "已初始化"}yield resource_dataprint("\n【Session Fixture Teardown】正在清理...")# 模拟清理操作time.sleep(0.5)# Module 作用域：每个模块只执行一次
@pytest.fixture(scope="module")
def module_data(expensive_resource): # Fixture 可以依赖其他 Fixtureprint(f"\n【Module Fixture Setup】正在准备模块数据，使用资源ID：{expensive_resource['id']}")data = {"module_id": "mod123", "resource_ref": expensive_resource['id']}yield dataprint("\n【Module Fixture Teardown】正在清理模块数据。")# Class 作用域：每个类只执行一次
@pytest.fixture(scope="class")
def class_context(module_data):print(f"\n【Class Fixture Setup】正在为类设置上下文，使用模块数据：{module_data['module_id']}")context = {"class_name": "MyTestClass", "module_ref": module_data['module_id']}yield contextprint("\n【Class Fixture Teardown】正在拆卸类上下文。")# Function 作用域 (默认)：每个函数执行一次
@pytest.fixture # scope="function" is default
def function_specific_data(expensive_resource):print(f"\n【Function Fixture Setup】正在获取函数数据，使用资源ID：{expensive_resource['id']}")data = {"timestamp": time.time(), "resource_ref": expensive_resource['id']}yield dataprint("\n【Function Fixture Teardown】正在清理函数数据。")# 使用 Class 作用域 Fixture 需要用 @pytest.mark.usefixtures 标记类 (或者方法参数注入)
@pytest.mark.usefixtures("class_context")
class TestScopedFixtures:def test_one(self, function_specific_data, module_data, class_context):print("\n【测试一】正在运行测试...")print(f"  使用函数数据：{function_specific_data}")print(f"  使用模块数据：{module_data}")print(f"  使用类上下文：{class_context}")assert function_specific_data is not Noneassert module_data is not Noneassert class_context is not None# 验证 Fixture 依赖关系 (间接验证作用域)assert function_specific_data["resource_ref"] == module_data["resource_ref"]assert module_data["module_id"] == class_context["module_ref"]def test_two(self, function_specific_data, module_data, class_context, expensive_resource):print("\n【测试二】正在运行测试...")print(f"  使用函数数据：{function_specific_data}")print(f"  使用模块数据：{module_data}")print(f"  使用类上下文：{class_context}")print(f"  直接使用 session 资源：{expensive_resource}")assert function_specific_data is not None# 验证不同函数的 function_specific_data 不同# (很难直接验证，但可以通过打印的 timestamp 或 id 观察)assert expensive_resource["status"] == "已初始化"# 另一个函数，也在同一个模块，会共享 module 和 session fixture
def test_outside_class(module_data, expensive_resource):print("\n【类外测试】正在运行测试...")print(f"  使用模块数据：{module_data}")print(f"  使用 session 资源：{expensive_resource}")assert module_data is not Noneassert expensive_resource is not None# 模拟一个连接函数 (用于后续例子)
def connect_to_real_or_mock_db():print("    (模拟数据库连接...)")return MockDbConnection()class MockDbConnection:def execute(self, query):print(f"    执行查询: {query}")return [{"result": "模拟数据"}]def close(self):print("    (模拟数据库关闭)")

运行 pytest -s -v 并观察输出：
在这里插入图片描述

你会注意到：

expensive_resource (session) 的 Setup 和 Teardown 只在所有测试开始前和结束后各执行一次。
module_data (module) 的 Setup 和 Teardown 在该模块的第一个测试开始前和最后一个测试结束后各执行一次。
class_context (class) 的 Setup 和 Teardown 在 TestScopedFixtures 类的第一个测试方法开始前和最后一个测试方法结束后各执行一次。
function_specific_data (function) 的 Setup 和 Teardown 在 test_one 和 test_two 执行时分别执行一次。

选择合适的作用域至关重要：

对于成本高昂、状态不应在测试间改变的资源（如数据库连接池、Web Driver 实例），使用 session 或 module。
对于需要在类级别共享的状态或设置，使用 class。
对于需要为每个测试提供独立、干净环境的资源（如临时文件、特定用户登录），使用 function。

注意: 高范围的 Fixture (如 session) 不能直接依赖低范围的 Fixture (如 function)，因为低范围 Fixture 可能在会话期间被创建和销毁多次。

4. 资源管理：Setup/Teardown：`yield`

我们在第一个例子中已经看到了 yield 的使用。这是 Pytest Fixture 实现 Setup 和 Teardown 的推荐方式。

import pytest
# 假设 connect_to_real_or_mock_db 和 MockDbConnection 已定义 (如上个例子)@pytest.fixture
def db_connection():print("\n【Setup】正在连接数据库...")conn = connect_to_real_or_mock_db() # 假设这是一个连接函数yield conn # 将连接对象提供给测试，并在此暂停print("\n【Teardown】正在断开数据库连接...")conn.close() # yield 之后执行清理def test_db_query(db_connection):print("【测试】正在执行查询...")result = db_connection.execute("SELECT * FROM users")assert result is not None

yield 方式的优点：

代码集中: Setup 和 Teardown 逻辑写在同一个函数内，结构清晰。
状态共享: yield 前后的代码可以共享局部变量（如上面例子中的 conn）。
异常处理: 如果 Setup 代码（yield 之前）或测试函数本身抛出异常，Teardown 代码（yield 之后）仍然会执行，确保资源被释放。

另一种方式：request.addfinalizer

在 yield Fixture 出现之前，通常使用 request.addfinalizer 来注册清理函数。

import pytest
# 假设 connect_to_real_or_mock_db 和 MockDbConnection 已定义@pytest.fixture
def legacy_db_connection(request):print("\n【Setup】正在连接数据库...")conn = connect_to_real_or_mock_db()def fin():print("\n【Teardown】正在断开数据库连接...")conn.close()request.addfinalizer(fin) # 注册清理函数return conn # 使用 return 返回值def test_legacy_db_query(legacy_db_connection):print("【测试】正在执行查询...")result = legacy_db_connection.execute("SELECT * FROM products")assert result is not None

虽然 addfinalizer 仍然有效，但 yield 方式是更简洁的上下文管理器风格，是目前推荐的首选。

5. 参数化 Fixture：让 Fixture 更强大

有时，我们希望同一个 Fixture 能够根据不同的参数提供不同的 Setup 或数据。例如，测试一个需要不同用户角色的 API。

可以使用 @pytest.fixture 的 params 参数，并结合内置的 request Fixture 来实现。

import pytest# 参数化的 Fixture，模拟不同用户角色
@pytest.fixture(params=["guest", "user", "admin"], scope="function")
def user_client(request):role = request.param # 获取当前参数值print(f"\n【Fixture Setup】正在为角色创建客户端：{role}")# 模拟根据角色创建不同的客户端或设置client = MockAPIClient(role=role)yield clientprint(f"\n【Fixture Teardown】正在清理角色 {role} 的客户端")client.logout() # 假设有登出操作class MockAPIClient:def __init__(self, role):self.role = roleself.logged_in = Trueprint(f"  客户端已初始化，角色为 '{self.role}'")def get_data(self):if self.role == "guest":return {"data": "公共数据"}elif self.role == "user":return {"data": "用户专属数据"}elif self.role == "admin":return {"data": "所有系统数据"}return Nonedef perform_admin_action(self):if self.role != "admin":raise PermissionError("需要管理员权限")print("  正在执行管理员操作...")return {"status": "成功"}def logout(self):self.logged_in = Falseprint(f"  角色 '{self.role}' 的客户端已登出")# 使用参数化 Fixture 的测试函数
def test_api_data_access(user_client):print(f"【测试】正在测试角色 {user_client.role} 的数据访问权限")data = user_client.get_data()if user_client.role == "guest":assert data == {"data": "公共数据"}elif user_client.role == "user":assert data == {"data": "用户专属数据"}elif user_client.role == "admin":assert data == {"data": "所有系统数据"}def test_admin_action_permission(user_client):print(f"【测试】正在测试角色 {user_client.role} 的管理员操作权限")if user_client.role == "admin":result = user_client.perform_admin_action()assert result == {"status": "成功"}else:with pytest.raises(PermissionError):user_client.perform_admin_action()print(f"  为角色 '{user_client.role}' 正确引发了 PermissionError")

运行 pytest -s -v：
在这里插入图片描述

你会看到 test_api_data_access 和 test_admin_action_permission 这两个测试函数，都分别针对 params 中定义的 “guest”, “user”, “admin” 三种角色各执行了一次，总共执行了 6 次测试。每次执行时，user_client Fixture 都会根据 request.param 的值进行相应的 Setup 和 Teardown。

params 和 ids:

你还可以提供 ids 参数，为每个参数值生成更友好的测试 ID：

@pytest.fixture(params=[0, 1, pytest.param(2, marks=pytest.mark.skip)],ids=["零", "一", "跳过的二"])
def number_fixture(request):print(f"\n【参数化 Fixture】提供参数：{request.param}")return request.paramdef test_using_number(number_fixture):print(f"【测试】使用数字：{number_fixture}")assert isinstance(number_fixture, int)

这会生成如 test_using_number[零]、test_using_number[一] 这样的测试 ID，并且 跳过的二 对应的测试会被跳过。

参数化 Fixture 与 @pytest.mark.parametrize 的区别：

@pytest.mark.parametrize 是直接作用于测试函数，为其提供多组输入参数。
参数化 Fixture 是让 Fixture 本身可以产生不同的输出（通常是 Setup 结果），使用该 Fixture 的测试函数会针对 Fixture 的每个参数化实例运行一次。
它们可以组合使用，实现更复杂的测试矩阵。

6. 自动使用的 Fixture (`autouse`)：便利性与风险

默认情况下，测试函数需要显式地在其参数列表中声明它所依赖的 Fixture。但有时，我们希望某个 Fixture 对某个范围内的所有测试都自动生效，而无需在每个测试函数中都写一遍参数。这就是 autouse=True 的用途。

import pytest
import time# 一个自动使用的 Session Fixture，例如用于全局日志配置
@pytest.fixture(scope="session", autouse=True)
def setup_global_logging():print("\n【自动 Session Setup】正在配置全局日志...")# configure_logging() # 假设这里配置日志yieldprint("\n【自动 Session Teardown】正在关闭日志系统。")# 一个自动使用的 Function Fixture，例如每次测试前重置某个状态
_test_counter = 0
@pytest.fixture(autouse=True) # scope is function by default
def reset_counter_before_each_test():global _test_counterprint(f"\n【自动 Function Setup】正在重置计数器。当前值：{_test_counter}")_test_counter = 0yield# yield 后的清理代码会在测试函数执行后运行print(f"【自动 Function Teardown】测试完成。计数器现在是：{_test_counter}")def test_increment_counter_once():global _test_counterprint("【测试】计数器增加一。")_test_counter += 1assert _test_counter == 1def test_increment_counter_twice():global _test_counterprint("【测试】计数器增加二。")_test_counter += 1_test_counter += 1assert _test_counter == 2# 这个测试函数没有显式请求任何 Fixture，但 autouse Fixture 仍然会执行
def test_simple_assertion():print("【测试】运行一个简单的断言。")assert True

运行 pytest -s -v：
在这里插入图片描述

你会看到：

setup_global_logging 在整个会话开始和结束时执行。
reset_counter_before_each_test 在 test_increment_counter_once, test_increment_counter_twice, 甚至 test_simple_assertion 这三个测试函数执行之前和之后都执行了。

autouse 的优点：

方便: 对于必须在每个测试（或特定范围内所有测试）之前运行的通用设置（如日志、数据库事务回滚、模拟 Patcher 启动/停止）非常方便。

autouse 的风险和缺点：

隐式依赖: 测试函数的依赖关系不再明确地体现在参数列表中，降低了代码的可读性和可维护性。当测试失败时，可能难以追踪是哪个 autouse Fixture 导致的问题。
过度使用: 滥用 autouse 会使测试环境变得复杂和不可预测。
作用域陷阱: autouse Fixture 只在其定义的作用域内自动激活。例如，一个 autouse=True, scope="class" 的 Fixture 只会对该类中的测试方法自动生效。

使用建议:

谨慎使用 autouse=True。
优先考虑显式 Fixture 注入，因为它更清晰。
仅对那些真正具有全局性、不言而喻且不直接影响测试逻辑本身的 Setup/Teardown 使用 autouse（例如，日志配置、全局 Mock 启动/停止、数据库事务管理）。
如果一个 Fixture 提供了测试需要的数据或对象，绝对不要使用 autouse=True，因为它需要被注入到测试函数中才能使用。autouse Fixture 通常不 yield 或 return 测试所需的值（虽然技术上可以，但不推荐）。

7. Fixture 的组合与依赖：构建复杂的测试场景

Fixture 的强大之处还在于它们可以相互依赖。一个 Fixture 可以请求另一个 Fixture 作为其参数，Pytest 会自动解析这个依赖链，并按照正确的顺序和作用域执行它们。

import pytest
import time# Fixture 1: 基础数据库连接 (Session 作用域)
@pytest.fixture(scope="session")
def db_conn():print("\n【数据库 Setup】正在连接数据库...")conn = {"status": "已连接", "id": int(time.time())} # 用时间戳模拟IDyield connprint("\n【数据库 Teardown】正在断开数据库连接...")conn["status"] = "已断开"# Fixture 2: 用户认证，依赖 db_conn (Function 作用域)
@pytest.fixture(scope="function")
def authenticated_user(db_conn):print(f"\n【认证 Setup】正在使用数据库连接 (ID: {db_conn['id']}) 认证用户...")assert db_conn["status"] == "已连接"user = {"username": "testuser", "token": "abc123xyz", "db_conn_id": db_conn['id']}yield userprint("\n【认证 Teardown】正在登出用户...")# Fixture 3: 用户购物车，依赖 authenticated_user (Function 作用域)
@pytest.fixture(scope="function")
def user_cart(authenticated_user):print(f"\n【购物车 Setup】正在为用户 {authenticated_user['username']} 创建购物车...")cart = {"user": authenticated_user['username'], "items": [], "token_used": authenticated_user['token']}yield cartprint("\n【购物车 Teardown】正在清空购物车...")cart["items"] = [] # 模拟清空购物车# 测试函数，直接请求最高层的 Fixture 'user_cart'
def test_add_item_to_cart(user_cart):print(f"【测试】正在为用户 {user_cart['user']} 添加物品到购物车")assert user_cart["token_used"] == "abc123xyz" # 验证依赖链正确传递user_cart["items"].append("product_A")assert len(user_cart["items"]) == 1assert "product_A" in user_cart["items"]# 另一个测试，也使用 'user_cart'
def test_cart_is_empty_initially(user_cart):print(f"【测试】正在检查用户 {user_cart['user']} 的购物车初始状态")assert len(user_cart["items"]) == 0# 测试可以直接请求中间层的 Fixture
def test_user_authentication(authenticated_user, db_conn):print(f"【测试】正在验证已认证用户 {authenticated_user['username']}")assert authenticated_user["token"] == "abc123xyz"assert authenticated_user["db_conn_id"] == db_conn["id"] # 验证依赖assert db_conn["status"] == "已连接" # 验证共享的 db_conn 状态

执行流程分析 (test_add_item_to_cart 为例):
在这里插入图片描述

Pytest 看到 test_add_item_to_cart 需要 user_cart。
Pytest 查找 user_cart Fixture，发现它需要 authenticated_user。
Pytest 查找 authenticated_user Fixture，发现它需要 db_conn。
Pytest 查找 db_conn Fixture，它没有其他 Fixture 依赖。
Pytest 执行 db_conn (Session 作用域，如果是第一次使用则执行 Setup，否则直接返回已存在的实例)。
Pytest 执行 authenticated_user (Function 作用域)，将 db_conn 的结果注入，执行到 yield user。
Pytest 执行 user_cart (Function 作用域)，将 authenticated_user 的结果注入，执行到 yield cart。
Pytest 执行 test_add_item_to_cart 函数体，将 user_cart 的结果注入。
test_add_item_to_cart 执行完毕。
Pytest 回到 user_cart，执行 yield 后的 Teardown。
Pytest 回到 authenticated_user，执行 yield 后的 Teardown。
Pytest 回到 db_conn (只有在整个 Session 结束时才会执行 Teardown)。

作用域在依赖链中的影响:

高作用域的 Fixture 可以被低作用域的 Fixture 依赖。
低作用域的 Fixture 不能被高作用域的 Fixture 依赖。例如，session 作用域的 Fixture 不能依赖 function 作用域的 Fixture。Pytest 会报错。
当多个测试共享一个高作用域 Fixture 实例时，依赖于它的低作用域 Fixture 在每次执行时，会接收到同一个高作用域 Fixture 的实例。

Fixture 组合是构建结构化、可维护测试套件的关键。它允许你将复杂的 Setup 分解为更小、更专注、可复用的单元。

8. 共享 Fixture：`conftest.py` 的妙用

当你的项目逐渐变大，你可能会发现很多 Fixture 需要在多个测试文件（模块）之间共享。将这些共享的 Fixture 放在哪里最合适呢？答案是 conftest.py 文件。

conftest.py 的特点：

这是一个特殊命名的文件，Pytest 会自动发现它。
放在测试目录下的 conftest.py 文件中的 Fixture，对该目录及其所有子目录下的测试文件都可见，无需导入。
你可以有多个 conftest.py 文件，分别位于不同的目录下，它们的作用域限于所在的目录树。
根目录下的 conftest.py 中的 Fixture 对整个项目的所有测试都可见。

示例目录结构:

my_project/
├── src/
│   └── my_app/
│       └── ...
├── tests/
│   ├── conftest.py         # (全局或通用 Fixtures)
│   ├── unit/
│   │   ├── conftest.py     # (单元测试特定的 Fixtures)
│   │   ├── test_module_a.py
│   │   └── test_module_b.py
│   └── integration/
│       ├── conftest.py     # (集成测试特定的 Fixtures)
│       ├── test_api.py
│       └── test_db_interactions.py
└── pytest.ini

tests/conftest.py :

# tests/conftest.py
import pytest
import time# 一个全局共享的 Session Fixture
@pytest.fixture(scope="session")
def global_config():print("\n【全局 conftest】正在加载全局测试配置...")config = {"env": "testing", "timeout": 30}return config# 一个通用的数据库 Mock Fixture
@pytest.fixture
def mock_db():print("\n【全局 conftest】正在设置模拟数据库...")db = {"users": {1: "Alice"}, "products": {}}yield dbprint("\n【全局 conftest】正在拆卸模拟数据库...")

tests/unit/test_module_a.py :

# tests/unit/test_module_a.py
import pytest# 可以直接使用来自上层 conftest.py 的 Fixture
def test_user_exists(mock_db):print("【测试模块A】正在检查用户是否存在...")assert 1 in mock_db["users"]assert mock_db["users"][1] == "Alice"# 也可以使用全局的 Fixture
def test_config_loaded(global_config):print("【测试模块A】正在检查全局配置...")assert global_config["env"] == "testing"

测试结果输出如下：
在这里插入图片描述

tests/integration/test_api.py (示例):

# tests/integration/test_api.py
import pytest# 同样可以使用来自顶层 conftest.py 的 Fixture
def test_api_timeout(global_config):print("【API测试】正在检查API超时配置...")assert global_config["timeout"] == 30

测试结果输出如下：
在这里插入图片描述

conftest.py 的优势：

避免导入: 无需在每个测试文件中 from ... import fixture_name。
集中管理: 将共享的测试基础设施（Fixtures, Hooks）放在明确的位置。
作用域控制: 不同层级的 conftest.py 可以定义不同范围的共享 Fixture。

注意: 不要在 conftest.py 中放置测试用例 (test_ 开头的函数或 Test 开头的类)。conftest.py 专门用于存放测试支持代码。

9. 高级技巧与最佳实践

掌握了基础之后，我们来看一些能让你 Fixture 水平更上一层楼的技巧和实践。

Fixture 命名:
- 力求清晰、描述性强。db_connection, logged_in_admin_user, temp_config_file。
- 对于非 yield/return 值的 Setup/Teardown Fixture (常与 autouse 结合)，有时会使用下划线前缀（如 _setup_database），但这并非强制规范。清晰的名称通常更好。
保持 Fixture 简洁 (单一职责):
- 一个 Fixture 最好只做一件明确的事（如创建连接、准备数据、启动服务）。
- 通过 Fixture 依赖组合复杂场景，而不是创建一个庞大臃肿的 Fixture。

使用工厂模式 (Factory as Fixture):

有时你需要的不是一个固定的对象，而是一个能够创建特定类型对象的“工厂”。Fixture 可以返回一个函数或类。

import pytestclass User:def __init__(self, name, role):self.name = nameself.role = role@pytest.fixture
def user_factory():print("\n【Fixture】正在创建用户工厂")_created_users = []def _create_user(name, role="user"):print(f"  工厂正在创建用户：{name} ({role})")user = User(name, role)_created_users.append(user)return useryield _create_user # 返回内部函数作为工厂print("\n【Fixture Teardown】正在清理创建的用户...")# 可能需要清理工厂创建的资源，这里仅作示例print(f"  工厂共创建了 {len(_created_users)} 个用户。")def test_create_admin(user_factory):print("【测试】使用工厂创建管理员")admin = user_factory("blues_C", role="admin")assert admin.name == "blues_C"assert admin.role == "admin"def test_create_default_user(user_factory):print("【测试】使用工厂创建默认用户")guest = user_factory("小明")assert guest.name == "小明"assert guest.role == "user"

测试结果输出如下：
在这里插入图片描述

Fixture 覆盖 (Overriding):
- 子目录的 conftest.py 或测试模块本身可以定义与上层 conftest.py 中同名的 Fixture。Pytest 会优先使用范围更小的（更具体）的 Fixture。这对于针对特定模块或场景定制 Setup 非常有用。
利用 request 对象:
- Fixture 函数可以接受一个特殊的 request 参数，它提供了关于调用测试函数和 Fixture 本身的信息。
- request.scope: 获取 Fixture 的作用域。
- request.function: 调用 Fixture 的测试函数对象。
- request.cls: 调用 Fixture 的测试类对象（如果是在类方法中）。
- request.module: 调用 Fixture 的测试模块对象。
- request.node: 底层的测试节点对象，包含更多上下文信息。
- request.param: 在参数化 Fixture 中访问当前参数。
- request.addfinalizer(): 注册清理函数（旧方式）。
Fixture 中的错误处理:
- yield 方式的 Fixture 能很好地处理 Setup 或测试中的异常，确保 Teardown 执行。
- 在 Teardown 代码中也要考虑可能发生的异常，避免 Teardown 失败影响后续测试。
文档字符串 (Docstrings):
- 为你的 Fixture 编写清晰的文档字符串，解释它的作用、它提供了什么、以及它的作用域和可能的副作用。

10. 常见陷阱与避坑指南

作用域混淆:
- 陷阱: 在 function 作用域的测试中，期望 session 作用域 Fixture 的状态在每次测试后重置。
- 避免: 清晰理解每个作用域的生命周期。需要隔离状态时使用 function 作用域。
滥用 autouse:
- 陷阱: 过多使用 autouse 导致测试依赖关系模糊，难以调试。
- 避免: 优先显式依赖注入。仅在必要且不影响理解的情况下使用 autouse。

可变默认值问题 (虽然 Fixture 中不常见，但概念类似):

陷阱: 如果 Fixture 返回了一个可变对象（如列表、字典），并且作用域大于 function，那么所有共享该 Fixture 实例的测试都会修改同一个对象，可能导致测试间相互影响。
避免: 如果需要可变对象但测试间需隔离，要么使用 function 作用域，要么让 Fixture 返回对象的副本，或者使用工厂模式。

# 潜在问题示例
import pytest@pytest.fixture(scope="module")
def shared_list():print("\n【共享列表 Fixture Setup】返回一个空列表")# 这个列表实例将在模块的所有测试中共享return []def test_add_one(shared_list):print("【测试一】向共享列表添加 1")shared_list.append(1)assert shared_list == [1]def test_add_two(shared_list):# 如果 test_add_one 先执行，这里会失败！print(f"【测试二】向共享列表添加 2 (当前列表: {shared_list})")shared_list.append(2)# 期望是 [2]，但如果 test_add_one 先运行，实际列表是 [1, 2]assert shared_list == [2], "测试失败：列表状态被前一个测试修改"

修正： 要么改 scope="function"，要么让 Fixture yield [] (每次都生成新的)，或者使用工厂返回新列表。

复杂的 Teardown 逻辑:
- 陷阱: Teardown 代码过于复杂，容易出错或遗漏某些清理步骤。
- 避免: 尽量保持 Teardown 逻辑简单。如果复杂，可以封装到独立的函数或上下文管理器中，在 yield 后的代码块中调用。确保 Teardown 的健壮性，例如使用 try...finally。
Fixture 间的隐式状态依赖:
- 陷阱: Fixture A 修改了某个全局状态或外部资源，Fixture B（或测试本身）不显式依赖 A，却隐式地依赖 A 修改后的状态。
- 避免: 尽量让 Fixture 的依赖关系显式化。如果必须操作共享状态，确保逻辑清晰，并在文档中说明。