在接手過(guò)幾個(gè)中型以上的測(cè)試團(tuán)隊(duì)項(xiàng)目之后我越來(lái)越意識(shí)到一個(gè)規(guī)律幾乎所有測(cè)試工程腐爛的起點(diǎn)都是同一個(gè)文件——conftest.py。用pytest寫(xiě)過(guò)幾年測(cè)試的人應(yīng)該都有這種體驗(yàn)項(xiàng)目剛起步時(shí)conftest.py只有幾十行放兩個(gè)fixture就能跑通全部用例。半年后它開(kāi)始悄悄膨脹八個(gè)月后你發(fā)現(xiàn)它已經(jīng)快兩千行里面什么都有session級(jí)別的數(shù)據(jù)庫(kù)連接、各類(lèi)webdriver初始化、封裝的請(qǐng)求客戶(hù)端、各種hook函數(shù)、記錄日志的裝飾器、甚至還有從業(yè)務(wù)代碼里拷來(lái)的工具函數(shù)。沒(méi)人敢輕易動(dòng)它因?yàn)槟愀静恢肋@個(gè)文件里某個(gè)看似多余的fixture到底被多少個(gè)測(cè)試用例依賴(lài)著。這個(gè)文件一旦失控整個(gè)測(cè)試工程的可維護(hù)性就開(kāi)始斷崖式下跌。這篇文章就以重構(gòu)企業(yè)級(jí)conftest.py為切入點(diǎn)把我在實(shí)際項(xiàng)目中梳理出來(lái)的一套完整重構(gòu)思路、具體操作步驟和踩坑經(jīng)驗(yàn)整理出來(lái)希望能給同樣被這個(gè)文件折磨的人一些參照。1. 重構(gòu)前先摸清家底你的conftest.py病到什么程度了1.1 企業(yè)級(jí)conftest.py的典型癥狀我先說(shuō)說(shuō)什么樣的conftest.py算“企業(yè)級(jí)”。字面意義有點(diǎn)唬人其實(shí)就是測(cè)試用例數(shù)量上千、參與開(kāi)發(fā)的人超過(guò)三五個(gè)、測(cè)試環(huán)境不止一套、對(duì)接的第三方服務(wù)好幾個(gè)。這個(gè)規(guī)模下conftest.py如果沒(méi)有任何治理痕跡幾乎必然出現(xiàn)下面這些癥狀。第一個(gè)癥狀是單一文件膨脹。我從一個(gè)真實(shí)項(xiàng)目里看到過(guò)一份conftest.py2600多行包含70多個(gè)fixture、十幾個(gè)hook函數(shù)、5個(gè)輔助類(lèi)。這個(gè)文件本身就很難瀏覽編輯器打開(kāi)都會(huì)卡。更麻煩的是它里面的fixture名稱(chēng)大量重復(fù)比如同一個(gè)模塊的數(shù)據(jù)庫(kù)連接在session級(jí)別、module級(jí)別、function級(jí)別各定義了一份。出現(xiàn)這種情況的原因是不同開(kāi)發(fā)者在不同階段各寫(xiě)各的誰(shuí)也不知道別人已經(jīng)定義過(guò)類(lèi)似的東西干脆再加一個(gè)最后自然是災(zāi)難。第二個(gè)癥狀是fixture的作用域?yàn)E用。我見(jiàn)過(guò)一種很典型的使用方式為了省事把幾乎所有的fixture都定義成pytest.fixture(scopesession)。session級(jí)別的fixture只在測(cè)試會(huì)話(huà)開(kāi)始時(shí)執(zhí)行一次看起來(lái)效率很高但代價(jià)是狀態(tài)在用例之間被共享。一旦某個(gè)用例把數(shù)據(jù)庫(kù)里的數(shù)據(jù)改了后面幾百個(gè)用例跑的就是“被污染”的狀態(tài)。排查這種問(wèn)題非常痛苦因?yàn)槟悴淮_定是哪條用例先改了數(shù)據(jù)只能靠二分法不斷縮小范圍運(yùn)維成本極高。第三個(gè)癥狀是hook函數(shù)和工具函數(shù)的混入。有些項(xiàng)目會(huì)直接把pytest_collection_modifyitems排序邏輯、失敗重試邏輯、Allure報(bào)告整理邏輯全部塞進(jìn)conftest.py再把生成隨機(jī)字符串、解析配置文件、讀取環(huán)境變量這些小工具也一起寫(xiě)下邊。發(fā)這個(gè)文件的人出于好心覺(jué)得“反正都是給測(cè)試用的放在這里大家都能用”?？梢坏┻B“去找某個(gè)工具函數(shù)都要搜索半天”的時(shí)候這個(gè)文件就已經(jīng)變成了一座沒(méi)人理得清的地下倉(cāng)庫(kù)每個(gè)人都在往里面扔?xùn)|西卻沒(méi)有人在做整理。第四個(gè)癥狀是隱式依賴(lài)嚴(yán)重。autouseTrue的fixture數(shù)量超過(guò)五六個(gè)以后新來(lái)的同事基本只能靠翻代碼來(lái)猜哪些用例被偷偷注入了什么。一旦想刪掉某個(gè)autouse fixture你沒(méi)法通過(guò)搜索“這個(gè)fixture名在哪些用例里出現(xiàn)”來(lái)判斷影響面因?yàn)橛美a里可能壓根沒(méi)有引用它。這是重構(gòu)時(shí)最棘手的一種技術(shù)債因?yàn)樗倪B鎖反應(yīng)會(huì)擴(kuò)散到整個(gè)測(cè)試套件而不只是某一個(gè)文件。1.2 體檢的四個(gè)維度與判斷標(biāo)準(zhǔn)在動(dòng)手重構(gòu)之前我建議先給現(xiàn)有conftest.py做一次“體檢”用數(shù)據(jù)來(lái)支撐后續(xù)的拆分決策而不是憑感覺(jué)。第一個(gè)維度是行數(shù)和“密度”。打開(kāi)文件統(tǒng)計(jì)總行數(shù)再看fixture平均行數(shù)。如果一個(gè)文件的80%內(nèi)容都在定義fixture其余20%塞了hook、常量、工具函數(shù)基本可以確定需要拆分。我一般用兩條硬性標(biāo)準(zhǔn)超過(guò)800行的conftest.py就該啟動(dòng)重構(gòu)評(píng)估超過(guò)1500行必須重構(gòu)。這條標(biāo)準(zhǔn)聽(tīng)起來(lái)很武斷但實(shí)際執(zhí)行下來(lái)幾乎沒(méi)有例外。第二個(gè)維度是fixture依賴(lài)關(guān)系。逐個(gè)fixture記錄它依賴(lài)了哪些其他fixture、被哪些fixture依賴(lài)、在哪些用例中被引用?？梢杂胮ytest自帶的命令快速拉一個(gè)清單我在實(shí)操部分會(huì)詳細(xì)說(shuō)這里先提思路pytest的fixture機(jī)制會(huì)形成一個(gè)有向無(wú)環(huán)圖你把這個(gè)圖畫(huà)出來(lái)凡是出現(xiàn)在圖中間位置、同時(shí)被非常多層fixture依賴(lài)的節(jié)點(diǎn)就是最需要優(yōu)先治理的對(duì)象。比如一個(gè)session級(jí)的db_engine被幾十個(gè)fixture間接依賴(lài)它就是所有依賴(lài)的源頭必須先把它抽出來(lái)。第三個(gè)維度是作用域分布。把現(xiàn)有fixture按function/module/class/session統(tǒng)計(jì)個(gè)數(shù)。正常情況下一個(gè)設(shè)計(jì)良好的測(cè)試工程里function級(jí)別fixture應(yīng)該占絕大多數(shù)session級(jí)別應(yīng)該只用來(lái)準(zhǔn)備那些真正全局共享、且只讀的資源——比如配置文件、全局唯一的外部服務(wù)連接。如果你的session級(jí)別fixture超過(guò)總數(shù)的兩成說(shuō)明很多本應(yīng)該獨(dú)立化的狀態(tài)被過(guò)早共享了。作用域選大本質(zhì)上是拿隔離性換性能這在企業(yè)級(jí)項(xiàng)目里往往是得不償失的。第四個(gè)維度是復(fù)用情況。把名字相同的fixture、功能相似的fixture列出來(lái)統(tǒng)計(jì)有多少測(cè)試模塊自己又額外定義了完全重復(fù)的fixture。這種重復(fù)通常是在“不知道conftest.py里已經(jīng)有現(xiàn)成的”這個(gè)前提下發(fā)生的。檢查手段是靠代碼檢索工具搜索所有測(cè)試文件里pytest.fixture的定義人工比對(duì)一輪。很多團(tuán)隊(duì)的重復(fù)率高達(dá)三成這意味著重構(gòu)后光是刪除重復(fù)代碼就能讓測(cè)試收集時(shí)間快一大截。體檢做完你會(huì)得到一張Excel表或者一份文檔里面列著現(xiàn)有fixture清單、每個(gè)fixture的實(shí)現(xiàn)行數(shù)、依賴(lài)方向、作用域、被引用范圍。有了這份清單接下來(lái)劃分模塊才有依據(jù)。沒(méi)有這份清單就直接重構(gòu)本質(zhì)上是在賭運(yùn)氣。2. 重構(gòu)方案選型不是把大文件拆成小文件這么簡(jiǎn)單2.1 為什么不能簡(jiǎn)單按行數(shù)切分很多人一聽(tīng)到重構(gòu)第一反應(yīng)就是把conftest.py從中間咔嚓一刀切成兩個(gè)文件。這種做法的確能讓每個(gè)文件的行數(shù)降下來(lái)但如果沒(méi)有解決依賴(lài)和邊界問(wèn)題半年后每個(gè)子文件又會(huì)膨脹成新的“小conftest”。拆分不是目的讓每個(gè)模塊的職責(zé)清晰、邊界穩(wěn)定、可獨(dú)立維護(hù)才是目的。我在早期的項(xiàng)目里也犯過(guò)這個(gè)錯(cuò)誤。當(dāng)時(shí)把conftest.py按“前半部分fixture、后半部分hook”一刀切結(jié)果兩個(gè)文件之間互相引用然后必須靠pytest_plugins來(lái)來(lái)回回加載最后因?yàn)榧虞d順序問(wèn)題到處報(bào)錯(cuò)折騰了一周。后來(lái)想明白了切分文件的核心是按照“領(lǐng)域”而不是“行數(shù)”來(lái)切。fixture和它管理的外部資源要放在一起不是把所有fixture放在一起。一個(gè)webdriver初始化的fixture就該和瀏覽器相關(guān)的一整套機(jī)制放在同一個(gè)模塊而不是和數(shù)據(jù)工廠(chǎng)fixture排排坐。2.2 分層架構(gòu)怎么設(shè)計(jì)結(jié)合多個(gè)項(xiàng)目的重構(gòu)經(jīng)驗(yàn)我建議采用“三層結(jié)構(gòu) 領(lǐng)域模塊”的組合方式。這套結(jié)構(gòu)不是憑空想的而是從后端框架的分層思想借鑒過(guò)來(lái)的測(cè)試工程同樣需要分層的概念。第一層是全局層對(duì)應(yīng)測(cè)試目錄最頂層的conftest.py。這層只放三類(lèi)東西pytest插件的注冊(cè)、全局級(jí)別的hook函數(shù)、極少數(shù)真正全局共享且只讀的session fixture比如統(tǒng)一的臨時(shí)目錄策略、全局性的命令行參數(shù)注入。你只要讓這一層精簡(jiǎn)到不做任何具體業(yè)務(wù)它就很難再腐化。每次有人想把新東西塞進(jìn)頂層conftest.py時(shí)都應(yīng)該先問(wèn)一句這個(gè)東西是所有模塊都要用的嗎如果不是請(qǐng)下移到領(lǐng)域?qū)?。第二層是領(lǐng)域?qū)訉?duì)應(yīng)每個(gè)業(yè)務(wù)模塊目錄下的conftest.py。這一層可以放該模塊專(zhuān)用的fixture和hook作用域以module為主負(fù)責(zé)給這個(gè)模塊的測(cè)試用例提供貼近業(yè)務(wù)場(chǎng)景的組件。比如訂單模塊的目錄下存放訂單狀態(tài)構(gòu)造的fixture用戶(hù)模塊下存放登錄態(tài)相關(guān)fixture。這樣做的收益是不同業(yè)務(wù)域的測(cè)試代碼互不干擾訂單模塊改了自己的fixture不會(huì)驚動(dòng)用戶(hù)模塊的測(cè)試。第三層是共享層對(duì)應(yīng)專(zhuān)門(mén)的fixtures包里面再按具體領(lǐng)域細(xì)分比如fixtures.db、fixtures.auth、fixtures.web、fixtures.data。這一層的模塊通過(guò)pytest_plugins機(jī)制被全局層加載供所有測(cè)試目錄使用。凡是多個(gè)模塊都會(huì)用到的東西放在這一層而不是放在某一個(gè)業(yè)務(wù)模塊的conftest里。這套結(jié)構(gòu)的核心思想是越通用的內(nèi)容層級(jí)越淺越業(yè)務(wù)化的內(nèi)容越靠向具體模塊。測(cè)試代碼和業(yè)務(wù)代碼一樣也需要依賴(lài)注入和分層邊界只是很多人寫(xiě)測(cè)試時(shí)沒(méi)有這個(gè)意識(shí)久而久之就形成了“一個(gè)大文件管所有事”的局面。2.3 具體目錄結(jié)構(gòu)長(zhǎng)什么樣我給出一個(gè)在實(shí)際項(xiàng)目中驗(yàn)證過(guò)的例子大家可以根據(jù)自己的業(yè)務(wù)替換模塊名。tests/ ├── conftest.py ├── fixtures/ │ ├── __init__.py │ ├── config.py │ ├── db.py │ ├── auth.py │ ├── web.py │ └── data.py ├── hooks/ │ ├── __init__.py │ ├── report.py │ └── retry.py ├── test_order/ │ ├── conftest.py │ ├── test_create.py │ └── test_query.py └── test_user/ ├── conftest.py ├── test_login.py └── test_profile.py注意這個(gè)結(jié)構(gòu)里我把hooks單獨(dú)放了一級(jí)。有讀者可能會(huì)問(wèn)hook函數(shù)為什么不能放在fixtures包頂層因?yàn)閔ook函數(shù)是在pytest框架生命周期里運(yùn)行的鉤子作用在“測(cè)試收集、執(zhí)行、報(bào)告”這些環(huán)節(jié)和fixture這種“為用例提供依賴(lài)”的能力是兩回事。放到一起還是職責(zé)混淆。hooks目錄里每個(gè)文件聚焦一種運(yùn)行行為report負(fù)責(zé)報(bào)告整理retry負(fù)責(zé)失敗重試需要在不同階段接管的pytest事件各管各的互不越界。頂層的conftest.py在我的方案里只負(fù)責(zé)兩件事注冊(cè)pytest_plugins、繼承那些必須全局生效的hook。它不再直接定義任何業(yè)務(wù)fixture。我實(shí)際測(cè)下來(lái)的效果是頂層conftest.py通常不超過(guò)60行非常清爽。# tests/conftest.py import pytest pytest_plugins [ fixtures.config, fixtures.db, fixtures.auth, fixtures.web, fixtures.data, hooks.report, hooks.retry, ] pytest.hookimpl(tryfirstTrue) def pytest_configure(config): 全局配置入口只在配置階段執(zhí)行一次。 ...順帶提醒一句pytest_plugins里的路徑是模塊路徑不是文件路徑且這套配置強(qiáng)烈建議放在測(cè)試根目錄頂層的conftest.py里。放在子目錄的conftest.py中時(shí)pytest的模塊加載機(jī)制容易引發(fā)ImportError這是官方文檔里明確標(biāo)注過(guò)的坑我在下文排查部分再展開(kāi)。3. 實(shí)操企業(yè)級(jí)conftest.py的完整重構(gòu)演練3.1 盤(pán)點(diǎn)與分類(lèi)先給fixture做臺(tái)賬現(xiàn)在開(kāi)始動(dòng)手。第一步是在重構(gòu)前把現(xiàn)有內(nèi)容全部盤(pán)點(diǎn)清楚我會(huì)用一個(gè)具體例子帶著大家走一遍流程。假設(shè)你的項(xiàng)目現(xiàn)在有一個(gè)tests/conftest.py1200行。先用一段腳本把所有fixture清點(diǎn)出來(lái)不需要太復(fù)雜正則匹配pytest.fixture和def中間的名字就行import ast from pathlib import Path source Path(tests/conftest.py).read_text(encodingutf-8) tree ast.parse(source) for node in tree.body: if isinstance(node, (ast.FunctionDef, ast.AsyncFunctionDef)): decorators [d.id if isinstance(d, ast.Name) else for d in node.decorator_list] if fixture in decorators: scope for dec in node.decorator_list: if isinstance(dec, ast.Call) and isinstance(dec.func, ast.Attribute): for kw in dec.keywords: if kw.arg scope: scope kw.value.value print(f{node.name}\tscope{scope}\tline{node.lineno})這段腳本只是拋磚引玉實(shí)際項(xiàng)目里你可能還要統(tǒng)計(jì)每個(gè)fixture的函數(shù)體行數(shù)、依賴(lài)的fixture名稱(chēng)通過(guò)解析函數(shù)參數(shù)。整理完之后把這些fixture按用途分成幾類(lèi)環(huán)境配置類(lèi)讀取環(huán)境變量、加載配置文件、臨時(shí)目錄、全局的ini參數(shù)。外部服務(wù)類(lèi)數(shù)據(jù)庫(kù)連接、Redis連接、MQ、第三方API客戶(hù)端、瀏覽器實(shí)例。狀態(tài)構(gòu)造類(lèi)造數(shù)據(jù)、構(gòu)造訂單、創(chuàng)建用戶(hù)、生成token、打樁返回mock數(shù)據(jù)。報(bào)告與運(yùn)行類(lèi)接管pytest hook比如失敗重試、展示優(yōu)化、性能埋點(diǎn)。這個(gè)分類(lèi)其實(shí)就是后續(xù)目錄結(jié)構(gòu)的雛形。大方向是環(huán)境配置類(lèi)進(jìn)fixtures/config.py外部服務(wù)類(lèi)按服務(wù)拆分狀態(tài)構(gòu)造類(lèi)按業(yè)務(wù)模塊分組報(bào)告與運(yùn)行類(lèi)進(jìn)hooks/。3.2 拆分動(dòng)作一按領(lǐng)域模塊遷移fixture分類(lèi)完成之后就開(kāi)始真正動(dòng)手。我強(qiáng)烈建議按“每遷一個(gè)fixture就全量跑一遍相關(guān)用例”的節(jié)奏推進(jìn)不要一次性把1200行全搬完再跑測(cè)試。一次性大遷移的問(wèn)題是出錯(cuò)之后你根本不知道是哪個(gè)fixture導(dǎo)致的排查范圍太大會(huì)讓人直接心態(tài)爆炸。以數(shù)據(jù)庫(kù)fixture為例。原來(lái)的代碼大概是這樣的# 重構(gòu)前在tests/conftest.py中 import pytest from db import get_engine, create_session pytest.fixture(scopesession) def db_engine(): engine get_engine() yield engine engine.dispose() pytest.fixture() def db_session(db_engine): session create_session(db_engine) yield session session.close()遷移到tests/fixtures/db.py之后代碼幾乎可以原樣保留唯一要注意的是如果這個(gè)模塊里還要定義其他fixture這些fixture的依賴(lài)關(guān)系必須在本模塊內(nèi)清晰可見(jiàn)。也就是說(shuō)db_session依賴(lài)db_engine兩者都在同一個(gè)模塊里這個(gè)模塊自洽別人閱讀這個(gè)文件就能把完整的依賴(lài)鏈看明白。# tests/fixtures/db.py import pytest from db import get_engine, create_session pytest.fixture(scopesession) def db_engine(): engine get_engine() yield engine engine.dispose() pytest.fixture() def db_session(db_engine): session create_session(db_engine) yield session session.close()然后頂層conftest.py里注冊(cè)fixtures.db即可。這里有個(gè)細(xì)節(jié)值得強(qiáng)調(diào)遷移fixture時(shí)要連同它依賴(lài)的所有外部資源接口一起考慮。比如db_engine讀取的是DATABASE_URL環(huán)境變量那這個(gè)讀取動(dòng)作是留在fixture內(nèi)部還是放到一個(gè)專(zhuān)門(mén)的config模塊里我傾向放到fixtures/config.py里定義一個(gè)app_configfixture再把配置值傳給db_engine。這樣做的原因是config模塊可以作為葉子節(jié)點(diǎn)被所有其他模塊依賴(lài)形成單向依賴(lài)鏈不會(huì)出現(xiàn)循環(huán)依賴(lài)。# tests/fixtures/config.py import os import pytest pytest.fixture(scopesession) def app_config(): return { database_url: os.getenv(DATABASE_URL, postgresql://localhost/testdb), api_base_url: os.getenv(API_BASE_URL, http://localhost:8080), timeout: int(os.getenv(HTTP_TIMEOUT, 30)), }# tests/fixtures/db.py 改造成這樣 pytest.fixture(scopesession) def db_engine(app_config): engine get_engine(app_config[database_url]) yield engine engine.dispose()依賴(lài)關(guān)系變得顯式哪個(gè)fixture需要什么配置一目了然。以后新增fixture時(shí)也只需要問(wèn)自己這個(gè)東西依賴(lài)的配置從哪里來(lái)把這條線(xiàn)的數(shù)據(jù)流理清楚conftest.py就很難再變成一鍋粥。3.3 拆分動(dòng)作二hook函數(shù)獨(dú)立管理hook函數(shù)是企業(yè)級(jí)conftest.py里容易被忽視的另一大塊。我將它們單獨(dú)規(guī)劃到hooks/目錄每個(gè)hook文件按職責(zé)組合不要一個(gè)文件放所有hook。這樣做的原因很簡(jiǎn)單hook函數(shù)操作的往往是pytest內(nèi)部對(duì)象item、config、call并且對(duì)執(zhí)行順序敏感把它們混在一起會(huì)導(dǎo)致排錯(cuò)時(shí)根本分不清是誰(shuí)改了誰(shuí)。舉個(gè)例子如果測(cè)試團(tuán)隊(duì)需要統(tǒng)計(jì)失敗用例并自動(dòng)重試一次可以封裝到hooks/retry.py# tests/hooks/retry.py import pytest pytest.hookimpl(tryfirstTrue) def pytest_runtest_makereport(item, call): 在用例執(zhí)行結(jié)束后判斷是否需要重試。 if call.when ! call: return if call.excinfo is not None and not hasattr(item, retried): item.retried True # 這里預(yù)留重試邏輯由外部runner統(tǒng)一調(diào)度再比如報(bào)告優(yōu)化類(lèi)hook比如給每個(gè)測(cè)試用例自動(dòng)打上模塊名稱(chēng)的標(biāo)簽# tests/hooks/report.py import pytest pytest.hookimpl(tryfirstTrue) def pytest_collection_modifyitems(config, items): 給收集到的每個(gè)用例自動(dòng)添加所屬模塊的mark。 for item in items: module_name item.module.__name__.split(.)[-1] item.add_marker(getattr(pytest.mark, module_name))這些hook之所以要獨(dú)立成模塊是因?yàn)樗鼈兺蕾?lài)pytest內(nèi)部狀態(tài)而且執(zhí)行順序敏感。和fixture混在一起會(huì)讓閱讀的人分不清“這個(gè)函數(shù)到底是普通工具還是pytest擴(kuò)展點(diǎn)”。獨(dú)立以后每個(gè)文件的頂部就能說(shuō)明它的用途排錯(cuò)時(shí)也容易定位。比如pytest運(yùn)行行為變得詭異就直接去hooks目錄下對(duì)應(yīng)的文件里看而不是在一個(gè)兩千行的文件里反復(fù)搜索。有一點(diǎn)要特別注意hook函數(shù)在不同模塊里定義時(shí)如果都設(shè)置了tryfirstTrue或trylastTrue執(zhí)行的先后順序會(huì)影響結(jié)果。遇到這類(lèi)依賴(lài)順序的hook建議在頂層conftest.py里統(tǒng)一顯式調(diào)度或者干脆把順序敏感的hook都放進(jìn)同一個(gè)模塊從上到下按順序定義不要拆開(kāi)。順序這種東西跨文件管理幾乎注定要出問(wèn)題。3.4 拆分動(dòng)作三配置與靜態(tài)資源外移除fixture和hook之外conftest.py里還經(jīng)常躺著兩類(lèi)東西靜態(tài)常量和資源路徑。比如各種超時(shí)時(shí)間、賬號(hào)密碼、URL前綴、模板路徑這些其實(shí)都不該出現(xiàn)在測(cè)試代碼里更不該散落在conftest.py的各處。重構(gòu)時(shí)我會(huì)把這類(lèi)內(nèi)容分三種方式處理與pytest運(yùn)行參數(shù)有關(guān)的配置寫(xiě)進(jìn)pytest.ini或pyproject.toml的[tool.pytest.ini_options]下。與運(yùn)行環(huán)境有關(guān)的變量統(tǒng)一從環(huán)境變量讀取集中到一個(gè)config模塊里管理。與業(yè)務(wù)相關(guān)的常量比如默認(rèn)訂單金額、默認(rèn)用戶(hù)名放到對(duì)應(yīng)的領(lǐng)域模塊目錄下的constants.py而不是塞給全局conftest。舉例說(shuō)明# pytest.ini [pytest] markers smoke: 冒煙用例 slow: 慢速用例 order: 訂單模塊用例 addopts -ra -q --strict-markers這些標(biāo)簽和命令行參數(shù)移出去之后conftest.py徹底和“運(yùn)行策略”解耦。如果后續(xù)要接CI流水線(xiàn)CI只需要修改ini文件里的參數(shù)或者通過(guò)命令行覆蓋不需要去碰測(cè)試代碼。這是一個(gè)非常容易被忽略的收益點(diǎn)很多項(xiàng)目直到接CI那天才發(fā)現(xiàn)conftest.py里的配置寫(xiě)得太死容器里一跑就各種水土不服。靜態(tài)資源路徑的遷移也同理。原來(lái)conftest.py里可能有個(gè)DATA_DIR Path(__file__).parent / data的常量它應(yīng)該被放到一個(gè)專(zhuān)門(mén)的config模塊中# tests/fixtures/config.py補(bǔ)充路徑部分 from pathlib import Path PROJECT_ROOT Path(__file__).resolve().parents[2] TEST_DATA_DIR PROJECT_ROOT / tests / data這樣所有需要讀測(cè)試數(shù)據(jù)的fixture統(tǒng)一從這個(gè)模塊取路徑。重構(gòu)之后數(shù)據(jù)的目錄結(jié)構(gòu)變化只需要改一個(gè)地方而不是全局搜索替換兩三種寫(xiě)法不同的路徑拼接。3.5 重構(gòu)完成后的驗(yàn)證清單拆分動(dòng)作全部做完以后我一般會(huì)走一遍驗(yàn)證清單逐項(xiàng)確認(rèn)沒(méi)有遺漏頂層conftest.py行數(shù)是否已經(jīng)壓到可維護(hù)范圍我建議控制在100行以?xún)?nèi)。每一個(gè)領(lǐng)域fixture模塊是否自洽模塊內(nèi)的fixture依賴(lài)關(guān)系清晰跨模塊依賴(lài)只有config層或公共服務(wù)層。pytest --fixtures輸出的fixture列表是否整潔名稱(chēng)無(wú)重復(fù)、無(wú)大量語(yǔ)義相近的名字。全量測(cè)試通過(guò)率是否和重構(gòu)前一致如果重構(gòu)前有失敗用例重構(gòu)后失敗用例集合應(yīng)該一致不能憑空多出一批新失敗。隨機(jī)抽幾個(gè)用例手動(dòng)驗(yàn)證會(huì)話(huà)級(jí)fixture的清理動(dòng)作是否生效比如數(shù)據(jù)庫(kù)連接確實(shí)被dispose了瀏覽器確實(shí)被關(guān)閉了。用pytest --collect-only -q確認(rèn)測(cè)試收集沒(méi)有遺漏或重復(fù)。我習(xí)慣在驗(yàn)證階段順手生成一份fixture清單快照存到docs里方便團(tuán)隊(duì)后續(xù)審查。以后任何人再往conftest.py里加fixture先對(duì)照快照看是否與已有fixture重復(fù)。這個(gè)動(dòng)作雖然簡(jiǎn)單但對(duì)保持重構(gòu)成果的作用相當(dāng)明顯。4. 重構(gòu)過(guò)程中的常見(jiàn)問(wèn)題與排查技巧4.1 fixture找不到或加載順序異常fixtures.*模塊注冊(cè)了但運(yùn)行測(cè)試時(shí)提示fixture xxx not found這是拆分后最常見(jiàn)的報(bào)錯(cuò)。我排查時(shí)按這個(gè)順序走。先確認(rèn)模塊路徑是否正確。pytest_plugins里寫(xiě)的是“模塊導(dǎo)入路徑”不是目錄路徑。假如tests/fixtures/db.py文件的包名叫fixtures.db并且tests/fixtures/目錄下有__init__.py這個(gè)導(dǎo)入才是合法的。如果沒(méi)有__init__.pypytest的導(dǎo)入機(jī)制雖然在某些版本下也能工作但強(qiáng)烈建議補(bǔ)上否則后續(xù)越發(fā)越亂。然后確認(rèn)頂層conftest.py里的pytest_plugins列表是否被覆蓋。有個(gè)很隱蔽的坑如果在conftest.py里把pytest_plugins放在某個(gè)函數(shù)內(nèi)部賦值或者用變量名覆蓋了它pytest根本不會(huì)讀取。它必須是一個(gè)模塊級(jí)別的名字且直接出現(xiàn)在conftest.py的頂層作用域。如果確認(rèn)了路徑?jīng)]問(wèn)題那就是加載順序問(wèn)題。pytest_plugins在列表中的順序雖然大體決定了加載順序但并不是絕對(duì)可靠的保障。當(dāng)模塊A的fixture依賴(lài)模塊B的fixture而B(niǎo)又依賴(lài)A時(shí)就形成了循環(huán)導(dǎo)入。解決辦法是打破循環(huán)把公共依賴(lài)抽到更底層比如都依賴(lài)config模塊。循環(huán)依賴(lài)是設(shè)計(jì)問(wèn)題靠調(diào)順序解決不了只能從依賴(lài)圖結(jié)構(gòu)上動(dòng)手。4.2 作用域膨脹導(dǎo)致測(cè)試串聯(lián)這是重構(gòu)后最容易暴露的存量問(wèn)題。session級(jí)fixture太多的時(shí)候用例之間“隱形串?dāng)?shù)據(jù)”特別嚴(yán)重。最常見(jiàn)的是數(shù)據(jù)庫(kù)session兩個(gè)用例先后修改了同一行記錄第二個(gè)用例斷言失敗可單獨(dú)跑第二個(gè)用例又是通過(guò)的。出現(xiàn)這種“單獨(dú)跑過(guò)、一起跑掛”的情況十有八九就是session級(jí)別共享狀態(tài)在作祟。重構(gòu)時(shí)遇到這類(lèi)問(wèn)題我的處理手法是把絕大多數(shù)數(shù)據(jù)庫(kù)相關(guān)的fixture降級(jí)到function級(jí)session級(jí)只保留連接池或engine。真正的CRUD操作session每次用例新建用完即關(guān)。這樣做的缺點(diǎn)是性能會(huì)略下降但換來(lái)的是隔離性。如果要兼顧性能可以在fixture里做“事務(wù)回滾”策略用例開(kāi)始時(shí)開(kāi)啟事務(wù)結(jié)束后回滾不真正commit。# tests/fixtures/db.py import pytest pytest.fixture() def db_session(db_engine): 每個(gè)用例獨(dú)立事務(wù)結(jié)束后回滾避免數(shù)據(jù)污染。 session create_session(db_engine) session.begin() yield session session.rollback() session.close()這個(gè)方案在單元測(cè)試和接口測(cè)試中都很實(shí)用。這里要注意如果代碼內(nèi)部自行commit了事務(wù)回滾就失效了需要配合嵌套事務(wù)或者讓代碼支持事務(wù)回調(diào)否則只能老老實(shí)實(shí)清理數(shù)據(jù)。遇到回滾失效時(shí)不要懷疑方案本身先檢查業(yè)務(wù)代碼里是不是把commit寫(xiě)死在了底層方法中。4.3 隱式依賴(lài)autouse濫用重構(gòu)過(guò)程中我問(wèn)得最多的一個(gè)問(wèn)題“這個(gè)autouse的fixture到底對(duì)哪些用例生效”答案往往是沒(méi)人說(shuō)得清。我遇到過(guò)一個(gè)團(tuán)隊(duì)conftest.py里autouse的fixture有7個(gè)分別做了設(shè)置locale、設(shè)置環(huán)境變量、創(chuàng)建臨時(shí)目錄、mock時(shí)間、mock了遠(yuǎn)程調(diào)用、修改了log級(jí)別、還預(yù)先加載了大批測(cè)試數(shù)據(jù)。結(jié)果就是每個(gè)用例跑起來(lái)都很慢但誰(shuí)都不敢動(dòng)因?yàn)椴恢绖h掉哪個(gè)會(huì)影響什么。我的建議是autouse只適用于那些“所有用例都無(wú)條件需要、且沒(méi)有副作用”的全局準(zhǔn)備動(dòng)作。比如設(shè)置一個(gè)全局性的環(huán)境變量確保每個(gè)用例都跑在測(cè)試環(huán)境這就是合理的autouse。而mock遠(yuǎn)程調(diào)用、加載數(shù)據(jù)這類(lèi)有業(yè)務(wù)語(yǔ)義的fixture應(yīng)當(dāng)顯式地在用例參數(shù)里聲明依賴(lài)讓代碼可讀性更強(qiáng)。如果在重構(gòu)時(shí)必須保留某個(gè)autouse fixture我建議在pytest_collection_modifyitems的hook里輸出一份日志打印每個(gè)用例被哪些autouse fixture注入了至少在排查時(shí)有線(xiàn)索。手動(dòng)搜索源碼根本找不到引用關(guān)系因?yàn)槟闼选皌mp_path”會(huì)搜出一堆結(jié)果但你根本沒(méi)法判斷哪個(gè)用例是隱式依賴(lài)的哪個(gè)是顯式聲明的。4.4 多環(huán)境配置管理企業(yè)級(jí)測(cè)試還有一個(gè)繞不開(kāi)的問(wèn)題dev、staging、test多套環(huán)境。很多團(tuán)隊(duì)把所有環(huán)境的地址寫(xiě)成常量放在conftest.py頂部每次手工改。重構(gòu)之后這部分被集中到config模塊配合TEST_ENV變量切換。我常用的做法是用os.getenv加默認(rèn)值同時(shí)加白名單校驗(yàn)# tests/fixtures/config.py import os ALLOWED_ENVS {dev, staging, test} pytest.fixture(scopesession) def app_config(): env os.getenv(TEST_ENV, dev) if env not in ALLOWED_ENVS: raise ValueError(f未知環(huán)境: {env}) return { env: env, database_url: os.getenv(fDATABASE_URL_{env.upper()}, postgresql://localhost/testdb), api_base_url: os.getenv(fAPI_BASE_URL_{env.upper()}, http://localhost:8080), }環(huán)境切換的入口收斂到一處CI里只需要注入TEST_ENV變量。這比在conftest.py里散落幾十個(gè)地址常量要穩(wěn)得多。還有一個(gè)附帶的好處寫(xiě)文檔的時(shí)候只需要說(shuō)明一組環(huán)境變量的命名規(guī)則而不是把每個(gè)環(huán)境的地址列成一個(gè)超長(zhǎng)表格。4.5 回歸風(fēng)險(xiǎn)控制最后聊一下重構(gòu)期間的回歸風(fēng)險(xiǎn)。我的經(jīng)驗(yàn)是所有前提中最重要的就是“小步走”。每次只遷一個(gè)fixture或者一個(gè)hook模塊遷移完立刻跑這一模塊相關(guān)的用例通過(guò)后再繼續(xù)。不要試圖用一整個(gè)周末把全量重構(gòu)完周一直接提交一個(gè)大PR——出了問(wèn)題光review就要一天情緒成本太高。另外重構(gòu)前給tests目錄做一個(gè)git分支跑一遍全量測(cè)試并記錄失敗清單。重構(gòu)完成后對(duì)照這份清單確保新引入的失敗用例為零。這個(gè)動(dòng)作看起來(lái)簡(jiǎn)單但很多團(tuán)隊(duì)?wèi)械米鲎詈笾貥?gòu)完上線(xiàn)發(fā)現(xiàn)一堆回歸反而對(duì)“重構(gòu)”這件事產(chǎn)生不信任。實(shí)際上大部分回歸問(wèn)題都是可以在小步遷移的過(guò)程中提前暴露的只是大家習(xí)慣性跳過(guò)了這一步。提示如果團(tuán)隊(duì)沒(méi)有統(tǒng)一格式化工具先統(tǒng)一引入flake8/ruff/black再進(jìn)行重構(gòu)?；熘煌L(fēng)格挪代碼后續(xù)diff查看會(huì)非常痛苦review的時(shí)候注意力都會(huì)被格式亂七八糟帶跑。5. 寫(xiě)在最后重構(gòu)之后怎么防止它再次腐爛到這里重構(gòu)流程已經(jīng)完整走過(guò)一遍。我想再分享一個(gè)實(shí)務(wù)層面的體會(huì)conftest.py之所以容易爛不是因?yàn)閷?xiě)代碼的人水平差而是因?yàn)樗烊痪吞幵谝粋€(gè)“極端方便”的位置——任何東西放進(jìn)去都能被所有測(cè)試立刻使用這種即時(shí)滿(mǎn)足感會(huì)讓大家無(wú)意識(shí)地在里面堆垃圾。重構(gòu)的作用是給這個(gè)文件立規(guī)矩但規(guī)矩立完還要有人維護(hù)。從個(gè)人經(jīng)驗(yàn)來(lái)說(shuō)重構(gòu)完成后最有效的一個(gè)制度是“fixture新增提案制”。雖然聽(tīng)起來(lái)有點(diǎn)形式主義但至少要讓團(tuán)隊(duì)約定新增fixture先看docs/fixtures.md清單確認(rèn)沒(méi)有現(xiàn)成的再?zèng)Q定是加到領(lǐng)域模塊還是共享層。我還會(huì)在CI里加一個(gè)輕量檢查如果頂層conftest.py行數(shù)超過(guò)150行直接讓流水線(xiàn)亮黃牌警告。限制文件行數(shù)說(shuō)白了很機(jī)械但對(duì)抑制膨脹確實(shí)立竿見(jiàn)影因?yàn)橐坏┏^(guò)閾值就會(huì)有人去問(wèn)“這東西為什么在這里”。最后再分享一個(gè)操作性很強(qiáng)的小技巧重構(gòu)后建議至少用一整周持續(xù)觀察pytest的收集時(shí)間和單條用例耗時(shí)。你很快會(huì)發(fā)現(xiàn)某些“看起來(lái)做了一次、實(shí)際上根本沒(méi)被用到”的session級(jí)fixture被刪除后收集時(shí)間會(huì)明顯縮短。如果發(fā)現(xiàn)重構(gòu)后收集時(shí)間反而變長(zhǎng)了優(yōu)先檢查是不是pytest_plugins列表里加載了過(guò)多不必要的模塊精簡(jiǎn)掉那些只在少數(shù)用例中使用的共享模塊改用業(yè)務(wù)模塊目錄下的局部conftest.py加載。