第一個問題：難道使用fixture 會影響用例獨立嗎？
? 簡單回答：
使用 fixture ≠ 不獨立。
只要你的 fixture 是每次測試都能自己運行、自己產生數據的，那么測試用例依然是“邏輯獨立”的。
? 怎么判斷 fixture 是否影響獨立性？
| 情況 | 是否影響獨立性 | 說明 |
|---|---|---|
| fixture 中 硬編碼共享數據（如共享 token） | ? 是耦合的 | 多個用例依賴同一數據，順序或狀態會影響結果 |
| fixture 每次調用都能 重新生成獨立數據 | ? 不影響 | 比如每個測試都生成新 token、新用戶 |
| fixture 被多個用例共享，且包含有狀態操作 | ? 可能影響 | 比如 fixture 中做了前置清理，多個測試共享它就有影響 |
| fixture 被一個用例專用 | ? 安全 | 就像把準備步驟封裝起來，依然獨立 |
📌 示例一：? 獨立的 fixture（沒問題）
pythonimport pytest
import requests@pytest.fixture
def valid_token():# 每次都調用登錄接口，獲取新 tokenresponse = requests.post("http://example.com/api/login", json={"username": "testuser","password": "123456"})assert response.status_code == 200return response.json()["token"]def test_user_info(valid_token):headers = {"Authorization": f"Bearer {valid_token}"}resp = requests.get("http://example.com/api/user/info", headers=headers)assert resp.status_code == 200
?? 這個 valid_token fixture 每次都是“自給自足”的，不依賴其他測試狀態，所以仍然是獨立用例。
?? 示例二：? 有耦合風險的 fixture
python# 假設 login_fixture 中手動生成了 token 或寫死一個 token
@pytest.fixture(scope="session")
def shared_token():return "abc1234567" # 固定寫死，或者由前置用例創建def test_user_info(shared_token):...
這個 shared_token fixture：
-
不一定來自當前測試生成
-
可能是別的用例產生或初始化時產生的
🛑 這種就存在耦合風險。如果別的地方修改了 token 或狀態，可能影響這個用例。
? 最佳實踐建議：
| 做法 | 推薦程度 | 理由 |
|---|---|---|
| 每個用例內部寫登錄邏輯 | 👍 簡單但冗余少量可接受 | ? 保證測試完全獨立，無需依賴外部狀態或 fixture，適合初學或用例量較少時 |
| 用 fixture 封裝登錄，但每次自動重新登錄 | ? 最推薦 | ? 實現代碼復用 + 獨立性兼顧，每個用例拿到的 token 都是最新、唯一、干凈的 |
| 共享全局 token、session 作為 fixture | ?? 僅限于性能優化場景，否則不推薦 | ?? 存在用例狀態耦合、測試順序依賴等風險，若 token 被修改或過期會影響所有用例 |
📌 總結一句話：
只要 fixture 是“每個用例都能獨立用”的工具，它就是幫助測試保持獨立的；只有當它變成“多個測試共用的狀態容器”，才會破壞獨立性。
第二個問題：那scope="session"這種級別的都是耦合的嗎？
? 簡短回答：
不是所有 scope=“session” 的 fixture 都導致耦合，關鍵在于你放了什么內容進去。
🧠 深入理解：fixture 的 scope 只是控制“生命周期”，不等于是否“耦合”。
| scope 值 | 生命周期 | 舉例 |
|---|---|---|
| “function” | 每個用例都執行一次（默認） | 最獨立、最干凈 |
| “class” | 每個類只執行一次 | 類內測試共享 |
| “module” | 每個測試文件只執行一次 | 跨函數共享 |
| “session” | 整個測試執行過程只執行一次 | 所有用例共享，最廣 |
? 所以：是否“耦合”，取決于 fixture 內部內容是否有狀態 / 會變化 / 受上下文影響
📌 下面通過具體例子來解釋：
? 安全的 session 級別 fixture（無耦合）
python# 這是一個靜態配置類 fixture，和用例無狀態相關
@pytest.fixture(scope="session")
def base_url():return "http://example.com/api"
?? 這個不會耦合，因為它只是一個靜態值，多個用例共享沒有問題。
?? 有耦合風險的 session 級別 fixture（含狀態）
python@pytest.fixture(scope="session")
def shared_token():# 登錄一次，所有用例共用resp = requests.post("http://example.com/api/login", json={"username": "testuser", "password": "123456"})return resp.json()["token"]
🛑 如果某個測試改變了用戶狀態（比如禁用賬號、修改密碼），其它測試就會失敗。這就是“隱性耦合”。
? 推薦做法（平衡獨立性 & 性能）：
? 方案一：默認使用 function scope，保持測試獨立性
python@pytest.fixture
def fresh_token():# 每個用例登錄一次，獨立、干凈...
? 方案二：使用 session，但只放“無狀態的共享配置”
python@pytest.fixture(scope="session")
def env_config():return {"base_url": "http://example.com/api","headers": {"Content-Type": "application/json"}}
🔚 總結一句話：
scope=“session” 本身不是壞事，但如果 fixture 中包含用戶態、系統態、會變的內容，就可能導致耦合問題。配置類 OK，狀態類要謹慎。
)
