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