1. 為什么我還在用unittest聊聊這個老框架的底子先說個可能讓不少新人意外的事實即便到了今天翻開企業(yè)內(nèi)部那些跑了好幾年的自動化測試項目Python生態(tài)里出鏡率最高的依然是unittest而不是各種新潮的測試框架。我知道很多人第一反應(yīng)是unittest不是Python自帶的那個基礎(chǔ)庫嗎有什么好學(xué)的。但恰恰是這個被當(dāng)成基本功的東西在真實項目里被用歪的概率是最大的。我見過太多測試代碼是這樣寫的一個TestCase類里堆了五十個test方法setUp里連數(shù)據(jù)庫連接都順手建了某個測試失敗后后面一串用例跟著崩。我們也見過另一種極端——為了避開unittest的各種別扭項目組直接上pytest結(jié)果寫出來的用例風(fēng)格五花八門最后沒人敢改公共conftest。這兩種路我都走過今天這篇就是想從實際使用的角度把unittest這個框架從頭到尾捋一遍它的核心組件怎么配合、什么樣的用例設(shè)計能經(jīng)得住項目迭代、哪些坑是我花了好幾個晚上才排查出來的。它適合誰來讀如果你是剛?cè)腴T自動化測試、想把測試代碼寫得有章法的同學(xué)這篇能幫你把unittest的邏輯徹底理清。如果你已經(jīng)在用其他的測試框架這篇里關(guān)于fixture作用域、mock邊界、測試組織和排查思路的部分換到哪個框架里都一樣用。我們不講教科書式的定義堆砌只講在項目里真正靠得住的用法。補充一句我的立場這篇文章不是要吹unittest貶pytest兩個框架我都重度用過。弄清楚unittest的工作機制對你理解pytest的設(shè)計反而有幫助——pytest很多人性化的設(shè)計其實就是在給unittest的痛點打補丁。打蛇打七寸你總得先知道七寸在哪。2. 骨架拆解TestCase、TestSuite、TestRunner、TestLoader到底各管哪攤事很多教程喜歡把unittest四大組件列出來然后逐個念定義念完讀者還是不知道它們之間怎么聯(lián)動。我用一句話先建立起整體印象TestCase定義測試邏輯TestLoader負(fù)責(zé)發(fā)現(xiàn)和加載用例TestSuite把用例組織成可執(zhí)行的集合TestRunner執(zhí)行并輸出結(jié)果。一套標(biāo)準(zhǔn)的測試執(zhí)行流程就是這四樣?xùn)|西接力跑。2.1 TestCase一個用例類究竟該長什么樣先看一段最常見的代碼結(jié)構(gòu)import unittest class TestLogin(unittest.TestCase): classmethod def setUpClass(cls): # 整個測試類只執(zhí)行一次適合放耗時的公共初始化 cls.base_url https://api.example.com def setUp(self): # 每個test方法執(zhí)行前都會跑一遍適合做用例間的隔離 self.session create_test_session() def tearDown(self): # 每個test方法執(zhí)行后跑負(fù)責(zé)清理 self.session.close() def test_login_success(self): resp self.session.post(/login, json{name: user1, pwd: 123456}) self.assertEqual(resp.status_code, 200) self.assertIn(token, resp.json()) def test_login_wrong_password(self): resp self.session.post(/login, json{name: user1, pwd: wrong}) self.assertEqual(resp.status_code, 401) if __name__ __main__: unittest.main()關(guān)鍵的規(guī)矩是類里凡是以test開頭的方法都會被自動識別成測試用例執(zhí)行順序按方法名的字典序排。這個方法名排序經(jīng)?？拥饺撕竺嫖視ｉT講。其實按名字排序是有歷史原因的——最早的設(shè)計就是要保證多次運行結(jié)果一致從而讓測試可重復(fù)。真要靠執(zhí)行順序來控制用例依賴那基本就是把自己往火坑里推。fixture這塊我要多說一句。setUpClass / tearDownClass和setUp / tearDown的區(qū)別本質(zhì)是類級一次還是方法級多次。選型原則只有一條資源和時間成本高、且被所有用例共享的放類級或者模塊級需要每個用例獨立環(huán)境的放方法級。我以前在一個項目里見過有人把所有HTTP連接池初始化放在setUp里300個用例每個用例都重建一次連接池跑一遍要近一個小時。改成setUpClass之后時間直接砍到十幾分鐘。反過來如果你在setUpClass里初始化了一個可變對象又寫了好幾個test方法去改它這些測試就互相污染了——典型的共享可變狀態(tài)問題后面踩坑部分會展開。2.2 TestLoader和TestSuite怎么把散落的用例抓到一起unittest.main()適合玩具項目真實項目里測試分布在十幾個目錄你要的是有選擇地收集和執(zhí)行。這里就要用TestLoader了import unittest # 從指定目錄遞歸發(fā)現(xiàn)所有測試模塊 loader unittest.TestLoader() suite loader.discover(tests, patterntest_*.py) # 也可以按類/模塊直接加載 suite2 loader.loadTestsFromTestCase(TestLogin) suite3 loader.loadTestsFromModule(test_user_module)TestSuite則是手動組裝用例的容器suite unittest.TestSuite() suite.addTest(TestLogin(test_login_success)) suite.addTest(TestOrder(test_create_order))注意addTest的寫法它接收的參數(shù)是用例實例里的某個方法不是整個測試類。這在做冒煙測試集時特別有用——從各模塊把最核心的三五個用例撈出來組成smoke_suite每次發(fā)版前先跑它十幾分鐘就能拿到基本結(jié)論。實用命令再補兩個。在命令行指定模塊跑python -m unittest tests.test_login指定目錄跑python -m unittest discover -s tests -p test_*.py-m unittest discover這種方式能正常工作前提是tests目錄下有__init__.py或者你從項目根目錄啟動。常見報錯ModuleNotFoundError八成就是目錄結(jié)構(gòu)沒帶__init__.py導(dǎo)致Python不把tests當(dāng)成可導(dǎo)入的包。對這個問題卡過不少剛接觸的同學(xué)。2.3 TestResult除了綠和紅你還該看什么TestRunner把用例跑完之后產(chǎn)出的TestResult對象里面信息比終端顯示的多得多。它可以告訴你成功多少、失敗多少、報錯多少、跳過多少、預(yù)期失敗多少。result unittest.TestResult() suite.run(result) print(result.testsRun) print(result.failures) print(result.errors)failures和errors是有區(qū)別的這是新手最容易混淆的一點。failure 斷言沒通過即預(yù)期與實際不符error 用例執(zhí)行過程拋了未捕獲異常?？吹絝ailure你應(yīng)該去查業(yè)務(wù)邏輯是不是被改動了看到error則優(yōu)先懷疑測試代碼本身或者環(huán)境依賴出了問題。區(qū)分這兩者能省下大量定位時間。我見過團隊把接口返回格式變動引發(fā)的AttributeError當(dāng)成了測試失敗來回查業(yè)務(wù)代碼查了半天才發(fā)現(xiàn)是協(xié)議變了導(dǎo)致測試代碼里的解析函數(shù)拋異常。知道error先看環(huán)境、failure先看業(yè)務(wù)這類問題一分鐘就能定位。3. 斷言的藝術(shù)從assertEqual到自定義斷言你的測試在多大程度上說真話斷言是整個測試用例的靈魂。斷言寫得好不好直接決定一個用例失敗時你能多快地定位到問題。我經(jīng)?？吹接腥藬嘌詫懙煤芊笱鼙热缢薪涌谥粰z查HTTP 200結(jié)果下游解析字段時報KeyError——這個200除了說明服務(wù)沒掛什么信息量都沒有。3.1 內(nèi)置斷言到底覆蓋了多少場景unittest的斷言方法比很多人以為的要多。最常用的這些建議全部吃透斷言方法適用場景常見誤用assertEqual / assertNotEqual數(shù)值、字符串、對象比較用assertTrue(a b)代替失敗時沒有詳細(xì)上下文assertTrue / assertFalse布爾條件判斷所有斷言都用它丟失類型比較能力assertIs / assertIsNotNone判斷、對象身份用assertEqual(None, x)語義不清晰assertIn / assertNotIn成員關(guān)系判斷手動寫if x in list失敗時無上下文assertAlmostEqual浮點數(shù)比較可指定小數(shù)位直接assertEqual兩個浮點數(shù)精度問題隨機失敗assertRaises驗證期望的異常手動try/except包裹繞一大圈還容易漏assertRegex正則匹配響應(yīng)內(nèi)容先re.search再加assertTrue多寫三行代碼assertDictEqual / assertListEqual容器對象比對assertEqual失敗時diff信息不夠直觀我想單獨聊一下assertRaises。這個斷言有兩種寫法上下文管理器版本是最推薦的# 推薦的寫法 with self.assertRaises(ValueError): parse_user_input() # 另一種寫法可同時拿到異常對象做額外檢查 with self.assertRaises(ValueError) as cm: parse_user_input() self.assertEqual(cm.exception.code, 1001)setUp里放了一堆無關(guān)的耗時操作。有人為了省事把所有用例可能需要的資源全部塞進setUp()結(jié)果單個簡單用例跟著背了十幾秒初始化的鍋。正確做法是區(qū)分核心依賴和邊緣設(shè)施核心放setUpClass或模塊級邊緣設(shè)施按用例按需加載。斷言寫得太聰明。有些同學(xué)喜歡在斷言里塞復(fù)雜表達式比如self.assertTrue(any(item[status] done for item in resp_list))。用例失敗時你能看到的只是True is not false根本不知道resp_list里實際有什么。改成先篩出結(jié)果再斷言列表非空失敗信息就直觀多了。寫斷言的時候多想想這行代碼失敗時你希望自己看到什么。對我印象最深的一次同事寫了個測試斷言user.name ! 結(jié)果某天user是None拋了AttributeError報錯信息完全沒說是哪個用例哪一行。排查一個多小時才發(fā)現(xiàn)是mock沒打上。這類問題如果一開始就注意斷言的可讀性其實可以避免。3.2 自定義斷言給項目沉淀自己的黑話當(dāng)項目里某些判斷邏輯反復(fù)出現(xiàn)就該考慮封裝自定義斷言了。unittest支持通過子類擴展斷言方法規(guī)則是類里定義assertXxx開頭的方法失敗時拋AssertionErrorclass BaseAPITestCase(unittest.TestCase): def assertResponseOK(self, resp): self.assertEqual(resp.status_code, 200, fHTTP狀態(tài)碼異常: {resp.status_code}, body: {resp.text}) data resp.json() self.assertEqual(data.get(code), 0, f業(yè)務(wù)碼異常: {data}) return data class TestUserAPI(BaseAPITestCase): def test_get_user(self): resp self.client.get(/user/1) data self.assertResponseOK(resp) self.assertEqual(data[name], 張三)這筆賬很容易算封裝之前每個用例里要寫兩遍斷言一遍看HTTP狀態(tài)一遍看業(yè)務(wù)碼。封裝之后一個assertResponseOK搞定并且所有用例失敗時的報錯格式統(tǒng)一了。測試代碼也是代碼同樣要講DRY原則。3.3 浮點數(shù)比較assertEqual為什么會莫名其妙失敗這是個高頻坑。接口返回0.1你代碼里計算出來0.1兩個浮點數(shù)直接assertEqual偶爾會掛。原因在于浮點數(shù)的二進制表示天生有精度誤差0.1在計算機里實際存儲的是0.1000000000000000055511151231257827。兩邊計算路徑不同誤差累積就可能導(dǎo)致最后幾位不一致。解決辦法是assertAlmostEqual它會比較兩個數(shù)的差的絕對值是否在指定精度內(nèi)self.assertAlmostEqual(calc_result, api_result, places5)places5表示保留5位小數(shù)也即誤差容忍到0.00001。什么時候用幾乎相等金額計算、比例計算、多步運算后的浮點數(shù)結(jié)果這些場景用assertEqual就是給自己埋雷。整數(shù)和精確十進制場景則放心用assertEqual。4. 組織測試的工程化套路discover規(guī)則、子測試subTest、跳過機制單個用例寫得好只是第一步幾十上百個用例怎么組織才能長期維護是真正考驗工程能力的部分。這一節(jié)我講三個實際用下來回報率最高的組織套路。4.1 測試目錄設(shè)計discover怎么看到你的用例推薦一套經(jīng)過多項目驗證的目錄結(jié)構(gòu)project/ ├── src/ │ └── myapp/ │ ├── __init__.py │ ├── auth.py │ └── order.py └── tests/ ├── __init__.py ├── test_auth.py ├── test_order.py └── fixtures/ └── user_data.json這套結(jié)構(gòu)下從項目根目錄執(zhí)行python -m unittest discover -s tests -p test_*.pydiscover會遞歸掃描tests目錄下所有匹配test_*.py的文件并在每個文件里找TestCase的子類和test開頭的方法。有幾個細(xì)節(jié)值得注意模塊名重復(fù)會導(dǎo)致加載沖突。比如tests目錄下有test_auth.py另一個子目錄里也有test_auth.pydiscover可能只加載其中一個。解決辦法是保證模塊名全局唯一。導(dǎo)入路徑基于項目根目錄。運行命令時要在根目錄執(zhí)行或者把根目錄加進PYTHONPATH。很多新人是在tests目錄里直接跑discover然后發(fā)現(xiàn)from myapp.auth import ...報找不到模塊。因為腳本運行時當(dāng)前目錄變成了tests根本找不到src下的包。對比一下pytest在這塊的處理pytest會自動把項目根目錄插入sys.path所以不需要關(guān)心__init__.py這確實是省事。但理解背后的導(dǎo)入機制對排錯仍然重要。4.2 subTest一個用例里循環(huán)校驗多條數(shù)據(jù)拆還是不拆假設(shè)你要驗證搜索接口對10組關(guān)鍵詞的返回結(jié)果。最常見的寫法是def test_search_keywords(self): for keyword, expected_count in [(蘋果, 10), (香蕉, 5), ...]: resp self.client.get(/search, params{q: keyword}) data resp.json() self.assertEqual(data[total], expected_count)問題顯而易見第3組數(shù)據(jù)斷言失敗時整條用例直接中斷后面7組全不執(zhí)行而且失敗信息里根本看不出是哪組關(guān)鍵詞出了問題。用subTest重寫def test_search_keywords(self): cases [(蘋果, 10), (香蕉, 5), (西瓜, 8)] for keyword, expected_count in cases: with self.subTest(keywordkeyword): resp self.client.get(/search, params{q: keyword}) data resp.json() self.assertEqual(data[total], expected_count)subTest干的活是每一輪循環(huán)都算一個獨立的子測試。某個子測試失敗時其它子測試照常運行最后報告里明確列出是哪組keyword失敗、期望值和實際值分別是什么。對subTest的報錯展示非常直觀 FAIL: test_search_keywords (test_search.TestSearch) (keyword西瓜) ---------------------------------------------------------------------- AssertionError: 8 ! 6一眼看清楚是西瓜這組數(shù)據(jù)掛了。這種結(jié)構(gòu)在參數(shù)化場景里極致好用又不破壞unittest本身的框架約束。4.3 跳過測試什么時候用skip怎么避免濫用跳過測試有三種方式。unittest.skip(功能未開發(fā)完) class TestV2API(unittest.TestCase): ... unittest.skipIf(sys.platform win32, 該功能不支持Windows) def test_linux_only_feature(self): ... unittest.skipUnless(redis_available(), Redis未安裝) def test_cache(self): ...我個人的使用原則代碼還沒實現(xiàn)的用例用skip掛著依賴特殊環(huán)境的用skipIf/skipUnless。但skip要定期清理和復(fù)查拖太久就成了跳過一時爽上線火葬場。我見過一個項目里上百個skip裝飾器一查都是半年前加的沒人說得清這些功能到底好沒好。skip本來是為了給未就緒的東西一個體面的位置結(jié)果變成了拖延癥的溫床。一個務(wù)實的做法每次跳過的測試都附帶一個issue編號或者截止日期比如unittest.skip(TODO: 依賴外部廠商修復(fù)2025-06-30復(fù)審)。這樣定期清理時至少有線索可查不至于整個測試套件里堆一堆僵尸用例。5. 沒有接口也能測mock和patch的正確使用姿勢做測試的同學(xué)遲早會遇到這種情況代碼里調(diào)用了一個第三方支付接口或者要等某個下游服務(wù)凌晨兩點才開放。不mock測試根本沒法跑。unittest自帶的mock模塊正是干這個的。5.1 patch的三種打法從簡單到靈活from unittest.mock import patch, MagicMock # 方式一裝飾器 patch(myapp.services.payment.gateway.charge) def test_create_order_success(self, mock_charge): mock_charge.return_value {trx_id: 12345} ... # 方式二上下文管理器 def test_create_order_success(self): with patch(myapp.services.payment.gateway.charge) as mock_charge: mock_charge.return_value {trx_id: 12345} ... # 方式三start/stop手動控制適合setUp/tearDown場景 def setUp(self): self.patcher patch(myapp.services.payment.gateway.charge) self.mock_charge self.patcher.start() def tearDown(self): self.patcher.stop()這里最關(guān)鍵的一個認(rèn)知是patch里的路徑字符串指向的是使用該對象的位置不是定義該對象的位置。舉個例子你在myapp/services/payment.py里寫了from myapp.clients.pay_gateway import charge然后調(diào)用時直接用charge()函數(shù)。如果要mock它patch的目標(biāo)應(yīng)該寫myapp.services.payment.charge因為它已經(jīng)被導(dǎo)入到payment這個模塊的命名空間里。寫成myapp.clients.pay_gateway.charge是打不到的等于白打。這個細(xì)節(jié)坑了很多人測試跑起來還是真實調(diào)用下游接口一查才發(fā)現(xiàn)patch路徑寫錯了位置。5.2 side_effect才是mock的靈魂return_value只能讓mock返回固定值遇到第一次返回成功、第二次返回失敗這種帶狀態(tài)的場景就抓瞎了。side_effect可以傳入一組值每次調(diào)用依次返回mock_charge.side_effect [ {trx_id: 111}, # 第一次調(diào)用 TimeoutError(超時), # 第二次調(diào)用拋異常 {trx_id: 333}, # 第三次調(diào)用 ] mock_charge.side_effect lambda order_id: {trx_id: order_id}把side_effect設(shè)置為異常對象調(diào)用時就會拋異?！@其實是觸發(fā)assertRaises最優(yōu)雅的方式。用真實的下游服務(wù)去制造一個第三方超時代價太大mock一行就搞定了。5.3 什么時候不該用mock這個邊界要想清楚這是我最想強調(diào)的部分。mock好用但什么都mock會讓測試失去意義。一個項目如果所有外部服務(wù)全被mock測試就變成了純邏輯演練真實環(huán)境的連不通、協(xié)議對不齊、數(shù)據(jù)格式變化全都發(fā)現(xiàn)不了。我的經(jīng)驗是做如下分層該mock第三方不可控服務(wù)支付、短信、需要特定環(huán)境才出現(xiàn)的行為Windows下測Linux邏輯、代價極高的操作真實發(fā)送郵件。不該mock你自己服務(wù)的內(nèi)部邏輯、項目依賴數(shù)據(jù)庫層的表結(jié)構(gòu)變更——這些恰恰是回歸測試要抓住的東西。用一句話把握邊界mock應(yīng)該用來屏蔽不可控的外部因素而不是用來掩蓋被測代碼的真實行為。如果某個mock是為了讓測試通過而硬湊的它通常是個壞味道。6. 真實項目踩坑實錄四個讓我熬夜的典型問題這一節(jié)的內(nèi)容全部來自真實項目的排錯記錄。我盡量把詳細(xì)的排查鏈路寫出來而不是只給最終結(jié)論。因為這些問題的共同特點是表面上的現(xiàn)象和真正的原因差了不止一層。6.1 坑一用例一多就變慢問題出在setUp而不是代碼現(xiàn)象測試套件跑了一個半月之后單次執(zhí)行從20分鐘膨脹到55分鐘同事以為是代碼量增長導(dǎo)致。排查過程我用python -m unittest discover -s tests -v逐個記錄耗時發(fā)現(xiàn)一個非常普通的test_user_profile用例居然花了6秒。再看setUp里面竟然初始化了完整的數(shù)據(jù)庫連接池、Redis客戶端、消息隊列生產(chǎn)者和第三方支付客戶端。這些是當(dāng)初反正都要用順手加進去的。思路糾正setUp是每個test方法執(zhí)行前都要跑的任何寫在setUp里的初始化都會乘以測試用例總數(shù)。一個功能模塊的公共初始化應(yīng)該按需拆成setUpClass類級一次或模塊級fixture?；◣追昼娊osetUp做瘦身收益是幾何級的——尤其當(dāng)用例數(shù)從一兩百漲到上千時這個差距從能忍變成無法忍受。6.2 坑二同一套用例本地是綠的CI上必掛現(xiàn)象本地執(zhí)行全綠推到CI竟然隨機掛掉兩三個點開日志看是連接超時。第一反應(yīng)是CI機器網(wǎng)絡(luò)不行排查半天發(fā)現(xiàn)其實是并發(fā)問題。項目里的人為了提速讓CI上兩個workers并行跑測試。問題在于測試代碼里有一個共享的臨時文件多個進程同時在寫寫完一個進程把文件刪了另一個進程讀文件時FileNotFoundError。排查鏈路先看報錯堆棧指向的文件訪問再看有沒有進程間共享的可變資源。定位到臨時文件之后修復(fù)方案是把臨時文件改成按進程名隔離或者干脆用tempfile模塊自動生成每次不同的臨時路徑。測試用例之間要絕對隔離包括進程級別的隔離。寫測試時多問一句如果這個代碼被兩個進程同時跑會不會出事6.3 坑三測試A失敗測試B跟著失敗但B的代碼沒有錯現(xiàn)象test_auth_token_test失敗之后test_create_public_order必然也報錯。單跑test_create_public_order又是綠的。第一反應(yīng)是跑了什么全局初始化代碼順著調(diào)用棧去查確實在test_auth_token_test的setUp里有人把當(dāng)前進程的全局默認(rèn)時區(qū)改成了America/New_York。test_create_public_order里生成訂單編號用到了本地時間于是時間差導(dǎo)致斷言失敗。設(shè)計原則被違反得很典型setUp/tearDown里的全局副作用沒有在tearDown里恢復(fù)。修復(fù)很簡單tearDown里寫time.tzset()恢復(fù)到系統(tǒng)默認(rèn)時區(qū)。但更根本的問題是setUp里做全局副作用操作時要極其克制。測試框架的隔離不只是數(shù)據(jù)隔離還包括全局狀態(tài)環(huán)境變量、時區(qū)、目錄、配置單例的隔離。這就像用公用的廚房做完飯要收拾干凈不然下一個人進來根本沒法做飯。6.4 坑四assertEqual明明是一樣的為什么還是紅現(xiàn)象mock一個外部接口返回{total: 8}斷言self.assertEqual(data[total], 8)居然失敗日志顯示8 ! 8。排查到這里基本能鎖定類型問題。data是JSON解析出來的JSON數(shù)字有整數(shù)也有浮點json.loads(8)得到的是float 8.0而期望值是int 8。Python里8 8.0是True所以還能過但assertEqual({total: 8}, {total: 8.0})在dict比較時8和8.0是不同的key-value。更隱蔽的是有些JSON庫會把大整數(shù)解析成字符串或Decimal。這類問題排查起來很費勁因為你肉眼看到的數(shù)字一模一樣。定位方法在斷言前打印type。print(type(data[total]))一行就看出門道。修復(fù)統(tǒng)一接口返回數(shù)據(jù)的解析方案金額和計數(shù)類字段在做斷言前顯式轉(zhuǎn)成期望類型或者用Decimal比較。斷言之前先確認(rèn)類型一致可以省掉一大類看都看不懂為什么失敗的問題。我至今記得在一個數(shù)據(jù)驅(qū)動項目的上線準(zhǔn)備期測試報告里突然冒出一片! in的報錯肉眼看著完全一樣。最后發(fā)現(xiàn)就是類型——某些字段在test環(huán)境是字符串在某些環(huán)境是整數(shù)。測試的職責(zé)之一就是盡早暴露這類不一致暴露的時候不要慌先查類型再查值。7. unittest和pytest怎么選以及如何平滑過渡肯定會有人問現(xiàn)在pytest這么火我是不是應(yīng)該直接學(xué)pytest我的答案是項目的技術(shù)棧和團隊習(xí)慣決定選型但unittest是更普適的底子。而且凡是把unittest邏輯搞清楚的上手pytest也就是一天的功夫。7.1 兩者的核心差異一句話說清pytest相比unittest最大的變化有三點一是不用強制繼承TestCase類普通函數(shù)加test_前綴就能被識別二是fixture體系更靈活通過函數(shù)參數(shù)自動注入作用域和依賴關(guān)系表達得極清晰三是插件生態(tài)豐富allure報告、xdist并行、repeat重試全都能以插件方式無縫接入。舉例更直觀。unittest寫參數(shù)化需要subTest或者自己拼TestSuitepytest直接用裝飾器import pytest pytest.mark.parametrize(keyword,expected, [(蘋果, 10), (香蕉, 5)]) def test_search(keyword, expected): assert search_total(keyword) expectedfixture也直觀很多pytest.fixture def session(): s create_session() yield s s.close() def test_login(session): resp session.post(/login, ...) assert resp.status_code 200yield前面是setup后面是teardown讀起來就是準(zhǔn)備資源→執(zhí)行用例→清理資源。7.2 pytest到底比unittest進步在哪fixture作用域是pytest最值得學(xué)習(xí)的設(shè)計。unittest的setUp/tearDown只能區(qū)分方法級和類級做不到整個session共享一次或者每個模塊執(zhí)行一次。pytest的fixture可以精確聲明scopepytest.fixture(scopesession) def db_pool(): pool create_db_pool() yield pool pool.close()這個能力在實際項目中用處太大了數(shù)據(jù)庫連接池這種重資源理應(yīng)session級共享一次而每個用例獨立的數(shù)據(jù)準(zhǔn)備則用function級。unittest要用setUpClass去模擬session級效果很多場景下還力不從心。7.3 我的選型建議別盲目跟風(fēng)也別死守舊賬具體怎么選我的判斷依據(jù)是這樣的團隊已經(jīng)重度使用unittest沒有特別痛苦的點就繼續(xù)用?？蚣苓w移本身就是成本換個框架不會讓測試質(zhì)量變好好的設(shè)計習(xí)慣才是根本。新項目、成員以Python為主可以優(yōu)先考慮pytest。它的表達更簡潔參數(shù)化和fixture的工程化程度確實高。測試量大、并行需求強pytest-xdist帶來的進程級并行方案成熟適合測試集規(guī)模上了幾千之后。unittest要并行得自己去折騰進程池和報告合并。純單測、輕量場景unittest完全夠用少引入一個依賴也是一種工程減法。還有一條很實在的路pytest的框架本身兼容unittest編寫的測試用例。項目可以在現(xiàn)有unittest代碼上建立pytest運行入口pytest能自動收集unittest.TestCase類里的test方法不用重寫一行代碼就能先吃上pytest的插件生態(tài)。想遷移的時候這條平滑路徑能把風(fēng)險降到最低。把遷移看成漸進優(yōu)化而不是推倒重來心理壓力小得多。8. 寫在最后的實踐建議測試代碼最好的狀態(tài)是讓新人接手時能安心地改、放心地跑。這一點上統(tǒng)一的約定往往比花哨的框架更重要。我個人有幾個堅持了很久的習(xí)慣分享給你參考。第一個所有測試都要能獨立運行。單跑某個用例和跑整個套件結(jié)果必須一致。如果做不到這個基準(zhǔn)線其余一切都免談。第二個每個測試類只測一個維度。測試登錄的類就只寫登錄相關(guān)用例測試訂單的類就只寫訂單相關(guān)混在一起短期省事長期結(jié)構(gòu)就爛掉了。第三個套件執(zhí)行時間當(dāng)作工程質(zhì)量指標(biāo)來跟蹤。整體用時有明顯膨脹的時候別急著加機器先回去看是不是setUp里堆了太多東西、或者是用例之間出現(xiàn)了競爭。第四失敗信息要照顧好未來的自己。斷言里帶上具體的上下文報錯時能清楚看到哪個用例、哪組數(shù)據(jù)、期望值和實際值——這些信息的價值往往要在你說出這到底是在哪失敗的那一刻才體現(xiàn)得出來。如果你打算用unittest跑真實項目我最后再補充幾個直觀的小操作入門跑main工程化跑discover報錯看不懂先查_type再查值共享狀態(tài)要警惕mock路徑要打在使用處。把這五條變成肌肉記憶unittest這個老框架其實一點都不老——它的設(shè)計思路到今天仍然是自動化測試的基石而且很多新框架的便利恰恰是先把這些基礎(chǔ)邏輯吃透之后才體會得到的。