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