簡介這份 PDF 文檔面向剛接觸 Python 自動化測試與單元測試的開發(fā)者用可快速查閱的講義幫助理解 unittest 框架的基本用法與組織方式。資源包內(nèi)僅含 1 個 PDF 文件大小約 44KB輕量便于隨時打開閱讀適合需要梳理測試類結(jié)構(gòu)、斷言方法與用例執(zhí)行流程的初中級讀者。內(nèi)容圍繞 import unittest、繼承 unittest.TestCase 展開說明 setUp 初始化瀏覽器與基礎(chǔ) URL、收集 verificationErrorstearDown 關(guān)閉瀏覽器并清理資源以及以 test_ 開頭的測試方法如何被自動發(fā)現(xiàn)。文中還涉及 is_element_present、is_alert_present 等元素與彈窗判斷assertEqual 斷言suite()、makeSuite() 組合 TestSuiteTextTestRunner 與 unittest.main() 驅(qū)動測試并提到將用例分文件存放、用腳本批量執(zhí)行并輸出日志的思路。文中還強調(diào) setUp 與 tearDown 分別承擔(dān)測試前初始化、測試后清理斷言方法用于校驗返回值是否符合預(yù)期TestSuite 則把多個相關(guān)用例組織在一起便于在較大項目中統(tǒng)一管理與重復(fù)執(zhí)行。已有 120 人學(xué)習(xí)適合作為單元測試入門與用例管理參考。1. 別人在用 pytest我為什么還在項目里留著 unittest接手一個跑了三年的服務(wù)requirements.txt里除了 Web 框架什么都沒裝tests/目錄下卻躺著兩百多個test_*.py。執(zhí)行一條python -m unittest discover全綠耗時四秒。這種時候沒人有動力把它們遷到新框架上。unittest 是 Python 標(biāo)準(zhǔn)庫自帶的單元測試框架不裝任何依賴就能完成用例組織、測試發(fā)現(xiàn)、fixture 管理、斷言、打樁和套件編排。它的短板不在能力而在寫法斷言要背方法名fixture 靠命名約定參數(shù)化得自己寫循環(huán)。但如果目標(biāo)是在已有工程里補測試、給內(nèi)部 SDK 做回歸、或者在一個不允許隨便加第三方包的環(huán)境里交付unittest 依然是最省事的那條路。下面按「構(gòu)件 → 斷言 → fixture 與 mock → 命令行與覆蓋率 → 進(jìn)階技巧」的順序把它當(dāng)生產(chǎn)工具用一遍重點放在參數(shù)怎么設(shè)、失敗時看什么。2. unittest 四大構(gòu)件與斷言體系2.1 TestCase、TestSuite、TestLoader、TestRunner 各自管什么四個名字聽起來抽象實際職責(zé)很清晰。TestCase是用例容器一個繼承它的類里每個以test開頭的方法就是一條用例TestSuite是套件用來手工把若干用例或套件拼成執(zhí)行順序TestLoader負(fù)責(zé)從模塊和類里「抓」出用例并組裝成套件TestRunner負(fù)責(zé)跑TextTestRunner就是命令行里默認(rèn)那個輸出文本結(jié)果的實現(xiàn)。日常寫業(yè)務(wù)測試只需要碰TestCase其余三個在你要定制執(zhí)行順序、做分層冒煙時才會用到。import unittest class PriceCalc: 被測算價器rate 為折扣率 def __init__(self, rate): self.rate rate def total(self, amount, qty): return round(amount * qty * self.rate, 2) class TestPriceCalc(unittest.TestCase): def test_total_basic(self): calc PriceCalc(1.0) # 斷言浮點結(jié)果時先 round避免二進(jìn)制表示誤差 self.assertEqual(calc.total(9.99, 3), 29.97) def test_rate_zero(self): calc PriceCalc(0.0) self.assertEqual(calc.total(100, 2), 0.0) if __name__ __main__: unittest.main()這段代碼里沒有顯式構(gòu)造套件unittest.main()會自己用TestLoader掃描當(dāng)前模塊把TestCase子類中的test_*方法逐個裝進(jìn)套件再交給TextTestRunner執(zhí)行。執(zhí)行順序不是書寫順序而是方法名的字典序這一點在存在用例間隱式依賴時非常致命。2.2 斷言方法對照表與 assertRaises 的兩種寫法斷言是 unittest 最容易被寫錯的部分。選錯斷言方法不會讓測試立刻失敗卻會讓失敗信息完全無法定位問題。斷言方法判定條件典型場景assertEqual(a, b)a b返回值比對assertAlmostEqual(a, b, places7)差值在1e-places內(nèi)浮點、金額、坐標(biāo)assertIs(a, b)a is b單例、緩存命中判斷assertIn(a, b)a in b列表、字符串包含assertDictEqual(a, b)字典遞歸相等接口返回體assertCountEqual(a, b)元素計數(shù)相同忽略順序集合類結(jié)果assertRaises(Exc, fn, *args)調(diào)用拋出指定異常入?yún)⑿ｒ瀉ssertWarns(Warn)觸發(fā)指定警告廢棄接口assertLogs(logger, level)指定級別日志被輸出日志埋點回歸浮點比較是高頻事故點0.1 0.2 0.3在 Python 里是False用assertEqual寫金額斷言遲早翻車。異常斷言則有兩種寫法區(qū)別在于是否需要拿到異常對象。def parse_port(text): 把字符串端口轉(zhuǎn)成 int非法值直接拋 ValueError port int(text) # 非數(shù)字會拋 ValueError if not 0 port 65536: raise ValueError(fport out of range: {port}) return port class TestParsePort(unittest.TestCase): def test_context_manager_form(self): # with 形式斷言后還能讀 ctx.exception 檢查消息 with self.assertRaises(ValueError) as ctx: parse_port(70000) self.assertIn(out of range, str(ctx.exception)) def test_callable_form(self): # 可調(diào)用形式只關(guān)心拋了沒拋寫起來短 self.assertRaises(ValueError, parse_port, abc) def test_regex_form(self): # 消息匹配用 assertRaisesRegex正則里的點號記得轉(zhuǎn)義 with self.assertRaisesRegex(ValueError, rport out of range): parse_port(0)ctx.exception是 with 形式獨有的能力用來核對異常攜帶的上下文如果只關(guān)心異常類型可調(diào)用形式更省字符。還要注意assertRaises里若把斷言方法本身寫成self.assertRaises(ValueError, parse_port(abc))異常會在構(gòu)造參數(shù)時提前拋出測試直接報錯——這是最常見的寫法錯誤。2.3 測試發(fā)現(xiàn)規(guī)則文件名、類名與 discover 的關(guān)鍵參數(shù)python -m unittest不帶參數(shù)時等價于在當(dāng)前目錄執(zhí)行發(fā)現(xiàn)遞歸尋找匹配test*.py的文件導(dǎo)入其中的TestCase子類收集test開頭的方法。當(dāng)項目是src/tests/雙目錄結(jié)構(gòu)時必須顯式指定起點和頂層目錄否則相對導(dǎo)入會失敗。# -s 掃描起點目錄-p 文件名模式-t 頂層目錄決定 sys.path 插入位置 python -m unittest discover -s tests -p test_*.py -t . -v # 只跑某個模塊里的某個類走的是模塊路徑.類名的導(dǎo)入形式 python -m unittest tests.test_orders.TestRefund -v-t的作用常被忽略TestLoader會把top_level_dir插到sys.path最前面作為模塊導(dǎo)入的根。如果兩個子目錄下都存在test_utils.py且目錄里沒有__init__.pydiscover會因模塊同名沖突直接報錯補上空__init__.py把它變成包即可。另外被發(fā)現(xiàn)的文件必須能被正常import——語法錯誤、頂層執(zhí)行耗時邏輯、缺少依賴都會讓整個發(fā)現(xiàn)過程在收集階段就崩掉此時看不到任何用例結(jié)果。3. 讓測試可復(fù)現(xiàn)fixture 順序與 mock 姿勢3.1 四種 fixture 的執(zhí)行順序與作用域unittest 的 fixture 完全靠命名約定不掛裝飾器。搞不清調(diào)用次數(shù)就會出現(xiàn)數(shù)據(jù)庫連接被反復(fù)創(chuàng)建、臨時目錄沒清理干凈的連鎖問題。方法作用域調(diào)用次數(shù)該類有 n 條用例備注setUpClass類1必須加classmethodsetUp用例n每條用例執(zhí)行前各調(diào)一次tearDown用例n用例拋異常也會執(zhí)行tearDownClass類1必須加classmethodclass TestWithDb(unittest.TestCase): classmethod def setUpClass(cls): # 昂貴資源放在類級別連接池只建一次 cls.conn create_pool(minconn1, maxconn2) print(setUpClass once) def setUp(self): # 每條用例都要干凈的事務(wù)起點 self.tx self.conn.begin() def tearDown(self): # 回滾保證用例之間零污染 self.tx.rollback() classmethod def tearDownClass(cls): cls.conn.close() def test_insert_then_select(self): self.tx.execute(insert into t(id) values (1)) row self.tx.execute(select id from t where id1).fetchone() self.assertEqual(row[0], 1)順序上的坑有兩個setUp里拋異常時對應(yīng)的tearDown不會被調(diào)用setUpClass拋異常時該類下所有用例都會被標(biāo)記為 errortearDownClass也不會執(zhí)行。所以類級別的資源申請要在setUpClass內(nèi)部自己兜底清理別指望tearDownClass。另外用例執(zhí)行順序是方法名字典序任何依賴上一條用例副作用的寫法都會在某次改名后隨機(jī)崩掉。3.2 unittest.mockpatch 的三種寫法與 autospec打樁的目標(biāo)字符串是新人最容易寫錯的地方。規(guī)則只有一條patch 的是「被測試模塊里查找該對象的名字」而不是對象原本的定義位置。# app/notify.py import requests def send(url, payload): resp requests.post(url, jsonpayload, timeout3) return resp.status_code# tests/test_notify.py from unittest import mock import unittest from app import notify class TestSend(unittest.TestCase): # 寫法一裝飾器注意目標(biāo)串是 app.notify.requests.post mock.patch(app.notify.requests.post) def test_decorator(self, mock_post): mock_post.return_value.status_code 200 self.assertEqual(notify.send(http://api.local/hook, {a: 1}), 200) mock_post.assert_called_once_with( http://api.local/hook, json{a: 1}, timeout3 ) # 寫法二上下文管理器只覆蓋一小段邏輯 def test_context(self): with mock.patch(app.notify.requests.post) as mock_post: mock_post.side_effect TimeoutError(read timeout) with self.assertRaises(TimeoutError): notify.send(http://api.local/hook, {}) # 寫法三patch.object目標(biāo)已經(jīng) import 成模塊屬性時更直觀 def test_object(self): with mock.patch.object(notify.requests, post) as mock_post: mock_post.return_value.status_code 204 self.assertEqual(notify.send(http://api.local/hook, {}), 204) # 環(huán)境變量、字典類配置用 patch.dict 最省事退出時自動還原 def test_env(self): with mock.patch.dict(os.environ, {FEATURE_X: 1}): notify.send(http://api.local/hook, {})如果app/notify.py里寫的是from requests import post那么app.notify命名空間里綁定的名字就是postpatch 目標(biāo)必須改成app.notify.post寫app.notify.requests.post會因為屬性不存在直接報錯。給 patch 加autospecTrue能讓替身對象繼承真實函數(shù)的簽名調(diào)用參數(shù)寫錯時立刻拋TypeError比默默接受任意參數(shù)要安全得多。return_value控制返回值side_effect控制拋異?；虬错樞蚍祷囟鄠€值assert_called_once_with、call_args_list用來做調(diào)用校驗。3.3 subTest 參數(shù)化與外部資源隔離unittest 沒有原生參數(shù)化裝飾器常見做法是循環(huán)加subTest。直接循環(huán)不加subTest的后果是第一組數(shù)據(jù)失敗后循環(huán)中斷后面九組數(shù)據(jù)根本不會執(zhí)行。def slugify(text): return -.join(text.lower().split()) class TestSlugify(unittest.TestCase): def test_slugify_cases(self): cases [ (Hello World, hello-world), ( Trim Me , trim-me), (Already-dashed, already-dashed), ] for raw, expect in cases: with self.subTest(rawraw): # 每條數(shù)據(jù)獨立報告結(jié)果失敗不打斷后續(xù) self.assertEqual(slugify(raw), expect)外部資源隔離靠tempfile.TemporaryDirectory和addCleanup。addCleanup注冊的清理函數(shù)按后進(jìn)先出執(zhí)行即使用例斷言失敗也會被調(diào)用比寫在tearDown里逐條對應(yīng)更方便。import os, tempfile class TestFileSink(unittest.TestCase): def setUp(self): self.tmp tempfile.TemporaryDirectory() self.addCleanup(self.tmp.cleanup) # 用例結(jié)束自動刪除目錄 self.path os.path.join(self.tmp.name, out.txt) def test_write(self): with open(self.path, w, encodingutf-8) as f: f.write(ok) self.assertTrue(os.path.exists(self.path))4. 命令行參數(shù)、覆蓋率與 CI 落地4.1 python -m unittest 常用參數(shù)表命令行參數(shù)決定了排查效率。本地改代碼時用-f快速拿到第一個失敗CI 上反而要關(guān)掉它好一次看全所有失敗。參數(shù)作用使用建議-v逐條打印用例名與結(jié)果CI 日志必開-q只輸出匯總本地快速回歸-f/--failfast首個失敗即停止本地調(diào)試開CI 關(guān)-b/--buffer緩存 stdout/stderr失敗才回放降低日志噪音-c/--catch捕獲 Ctrl-C輸出已有結(jié)果長跑套件用-k按子串或通配過濾用例局部調(diào)試首選--locals回溯里打印局部變量定位難復(fù)現(xiàn)的失敗--durations N列出最慢的 N 條用例較新版本支持優(yōu)化套件用# 只跑名字里含 refund 的用例最快縮小范圍 python -m unittest discover -s tests -t . -k refund -v # 關(guān)注順序依賴時按字典序跑一遍再看是否有偶發(fā)失敗 python -m unittest discover -s tests -t . -b --durations 10退出碼要單獨記一下全部通過返回 0存在失敗或錯誤返回 1被中斷返回 2而沒有收集到任何用例時較新的 Python 會返回 5。很多流水線只判斷「非 0 即失敗」一旦-p模式寫錯導(dǎo)致零收集構(gòu)建會「成功」地跑完什么都沒有的測試。4.2 用 coverage.py 統(tǒng)計 unittest 的覆蓋率coverage.py與 unittest 的組合是標(biāo)準(zhǔn)解法用coverage run代替python啟動跑完再生成報告。pip install coverage # --source 限定只統(tǒng)計業(yè)務(wù)代碼避免把測試自身算進(jìn)去 coverage run --sourcesrc -m unittest discover -s tests -t . coverage report -m # 終端報告-m 會列出未覆蓋的行號 coverage html -d htmlcov # 生成可點擊的 HTML按行標(biāo)紅 coverage xml -o coverage.xml # 供 CI 插件讀取配置文件setup.cfg或.coveragerc里值得打開分支覆蓋否則if/else只走了一條分支也會算作覆蓋。[run] branch True source src omit */tests/*, */migrations/* [report] exclude_lines pragma: no cover raise NotImplementedError if TYPE_CHECKING:branch True會統(tǒng)計每個判斷點的真假分支是否都走到代價是覆蓋率數(shù)字下降但暴露的問題更真實。omit把測試目錄和自動生成的遷移腳本排除避免用無意義的行數(shù)稀釋指標(biāo)。別把覆蓋率當(dāng) KPI把fail_under設(shè)成 80 而不是 100才不至于逼著團(tuán)隊寫assert True湊數(shù)。4.3 在 CI 里穩(wěn)定運行 unittest 的配置自動化環(huán)境里最容易出問題的是隨機(jī)性來源哈希種子、時區(qū)、字典遍歷順序、依賴真實時鐘的斷言。把這幾項固定下來偶發(fā)失敗會少一大半。#!/usr/bin/env bash set -euo pipefail export TZUTC # 時區(qū)固定避免跨環(huán)境時間斷言漂移 export PYTHONHASHSEED0 # 關(guān)閉哈希隨機(jī)化集合遍歷順序可復(fù)現(xiàn) export PYTHONWARNINGSerror # 把 DeprecationWarning 升級為錯誤盡早暴露 python -m unittest discover -s tests -t . -v 21 | tee unittest.log coverage xml -o coverage.xml # 零用例視為失敗防止 -p 模式寫錯后假綠 grep -qE ^Ran [1-9][0-9]* test unittest.log || { echo no tests collected; exit 5; }逐行說明set -euo pipefail讓未定義變量和管道中任一環(huán)節(jié)失敗都能終止腳本tee保留完整日志便于事后翻查最后一行用grep校驗日志里的Ran N test且 N 大于零堵住「零用例也返回成功」的漏洞。另外若要把結(jié)果接入報告面板可用unittest-xml-reporting之類的外部 runner 產(chǎn)出 JUnit XML但本地回歸仍建議保留原生命令減少一層依賴帶來的行為差異。5. 進(jìn)階跳過、預(yù)期失敗與異步用例5.1 skipUnless 與 expectedFailure 的邊界跳過是帶條件的顯式聲明不是注釋掉的代碼。unittest.skipIf/unittest.skipUnless可以掛在類或方法上用條件表達(dá)式描述環(huán)境約束。import sys, unittest unittest.skipUnless(sys.version_info (3, 8), 需要 3.8) class TestModernSyntax(unittest.TestCase): def test_walrus(self): self.assertEqual((n : 3) 1, 4) unittest.expectedFailure def test_known_bug(self): # 已知缺陷上游表結(jié)構(gòu)未定先標(biāo)記為預(yù)期失敗 self.assertEqual(len(load_legacy_rows()), 0)expectedFailure的坑在于它反向生效如果這條用例真的通過了unittest 會報告unexpected success并且整個測試運行會被判定為失敗。這其實是設(shè)計上的保護(hù)防止缺陷被修好后標(biāo)記忘了摘。所以它只適合「短期待修復(fù)」的場景不適合長期掛著當(dāng)擺設(shè)——一旦發(fā)現(xiàn)有 XPASS要么摘掉標(biāo)記要么把它改回普通用例。5.2 IsolatedAsyncioTestCase每個用例一個獨立事件循環(huán)測異步函數(shù)別用asyncio.run()塞進(jìn)同步用例里那樣每條用例都新建和銷毀事件循環(huán)連接池、后臺任務(wù)這類資源無法正確復(fù)用或清理。標(biāo)準(zhǔn)庫提供了專門的基類asyncSetUp/asyncTearDown與同步版本一一對應(yīng)。import unittest class FakeSession: async def get(self, key): return bvalue class TestAsyncFetch(unittest.IsolatedAsyncioTestCase): async def asyncSetUp(self): self.session FakeSession() async def test_fetch_ok(self): data await fetch(self.session, k) self.assertEqual(data, bvalue) async def test_fetch_failure(self): with self.assertRaises(KeyError): await fetch(self.session, missing)注意每個用例各自跑在一個獨立事件循環(huán)里所以不要把事件循環(huán)對象存到類屬性上跨用例復(fù)用需要跨用例共享的異步資源放在asyncSetUp里按用例重建或者干脆用同步的setUpClass只準(zhǔn)備數(shù)據(jù)。涉及多線程與線程本地存儲時用addCleanup注冊thread.join()比在tearDown里手動關(guān)閉更穩(wěn)。5.3 用 -k 與 durations 把調(diào)試時間壓到最低日常改代碼最高頻的動作不是跑全量而是三步先python -m unittest tests.test_orders.TestRefund -v單跑一條確認(rèn)改動方向再-k refund按關(guān)鍵字掃一組相關(guān)用例確認(rèn)沒有波及同類邏輯最后去掉-k跑全量并加上--durations 10看這次改動是否把某條用例拖慢了一個數(shù)量級。這三個動作加起來通常不到三十秒比在 CI 上排隊等結(jié)果快得多。真正需要留意的是第三階段的輸出——如果某條用例的耗時突然從毫秒級漲到秒級八成是新增了真實網(wǎng)絡(luò)調(diào)用或未加索引的查詢而不是斷言本身變復(fù)雜了。本文還有配套的精品資源點擊獲取