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 的依賴關系顯式化。如果必須操作共享狀態，確保邏輯清晰，并在文檔中說明。