1. 項(xiàng)目概述從“跑通就行”到“穩(wěn)定可靠”的必經(jīng)之路干了這么多年開(kāi)發(fā)我見(jiàn)過(guò)太多項(xiàng)目在初期跑得飛快功能一個(gè)接一個(gè)地上但一到后期代碼就像一棟內(nèi)部結(jié)構(gòu)混亂的毛坯房牽一發(fā)而動(dòng)全身沒(méi)人敢動(dòng)。問(wèn)題出在哪很多時(shí)候缺的就是一套扎實(shí)的單元測(cè)試。這玩意兒聽(tīng)起來(lái)像是“學(xué)院派”或者大廠才搞的“奢侈品”但實(shí)際上它是保障我們?nèi)粘ｉ_(kāi)發(fā)效率、代碼質(zhì)量和長(zhǎng)期維護(hù)性的“必需品”。簡(jiǎn)單來(lái)說(shuō)單元測(cè)試就是對(duì)你寫(xiě)的每一小塊“磚頭”函數(shù)、方法、類(lèi)進(jìn)行獨(dú)立驗(yàn)證確保它在你期望的各種情況下都能正確工作。那么誰(shuí)該來(lái)寫(xiě)這些測(cè)試是測(cè)試工程師嗎不核心編寫(xiě)者應(yīng)該是開(kāi)發(fā)者自己。因?yàn)橹挥心阕钋宄@段代碼的設(shè)計(jì)意圖、輸入邊界和預(yù)期輸出。測(cè)試工程師更關(guān)注集成和系統(tǒng)層面的行為。單元測(cè)試怎么寫(xiě)絕不是簡(jiǎn)單調(diào)用一下函數(shù)看看不報(bào)錯(cuò)就行。它需要你像偵探一樣思考各種可能的輸入正常值、邊界值、異常值、甚至是故意搗亂的非法輸入然后斷言輸出是否符合預(yù)期。最近社區(qū)里討論挺多的比如如何對(duì)有狀態(tài)或及時(shí) UDF 和自定義算子進(jìn)行單元測(cè)試或者在Vue 項(xiàng)目中引入單元測(cè)試時(shí)遇到的各種報(bào)錯(cuò)這些都恰恰說(shuō)明了單元測(cè)試正在從可選動(dòng)作變成必選動(dòng)作其復(fù)雜性和重要性日益凸顯。無(wú)論你是剛?cè)胄械男率诌€是苦于維護(hù)“祖?zhèn)鞔a”的老手理解并實(shí)踐好單元測(cè)試都能讓你從“功能實(shí)現(xiàn)者”升級(jí)為“質(zhì)量構(gòu)建者”。這篇文章我就結(jié)合自己踩過(guò)的坑和總結(jié)的經(jīng)驗(yàn)跟你聊聊單元測(cè)試的“道”與“術(shù)”。2. 核心概念與價(jià)值為什么它不只是“多寫(xiě)點(diǎn)代碼”2.1 單元測(cè)試的定義與核心目標(biāo)單元測(cè)試顧名思義是對(duì)軟件中的最小可測(cè)試單元進(jìn)行檢查和驗(yàn)證。這個(gè)“單元”在過(guò)程化編程中通常指一個(gè)函數(shù)或過(guò)程在面向?qū)ο缶幊讨袆t是一個(gè)方法或類(lèi)。它的核心目標(biāo)有三個(gè)且一個(gè)比一個(gè)重要驗(yàn)證正確性這是最直接的目標(biāo)。確保單個(gè)單元的行為符合設(shè)計(jì)預(yù)期。比如你寫(xiě)了一個(gè)計(jì)算折扣的函數(shù)輸入原價(jià)和折扣率它得算出正確的折后價(jià)。促進(jìn)設(shè)計(jì)這是容易被忽視但價(jià)值極高的目標(biāo)。一段難以被測(cè)試的代碼往往意味著設(shè)計(jì)上有問(wèn)題比如耦合度過(guò)高、職責(zé)不單一。為了能方便地寫(xiě)測(cè)試你會(huì)自然而然地促使自己寫(xiě)出高內(nèi)聚、低耦合的代碼這反過(guò)來(lái)提升了代碼的設(shè)計(jì)質(zhì)量。這就是所謂的“測(cè)試驅(qū)動(dòng)開(kāi)發(fā)”TDD的核心思想之一測(cè)試先行倒逼設(shè)計(jì)。充當(dāng)活文檔與安全網(wǎng)一份好的單元測(cè)試集合就是代碼功能最準(zhǔn)確、最不會(huì)過(guò)時(shí)的說(shuō)明書(shū)。新同事接手模塊看測(cè)試用例能最快理解這段代碼該怎么用、邊界在哪里。更重要的是它是一張“安全網(wǎng)”在未來(lái)任何修改重構(gòu)、加功能、修Bug后運(yùn)行一遍測(cè)試就能快速確認(rèn)有沒(méi)有破壞已有的功能極大增強(qiáng)你修改代碼的信心。注意很多人把“單元測(cè)試”和“集成測(cè)試”搞混。單元測(cè)試強(qiáng)調(diào)“隔離”它不應(yīng)該依賴(lài)數(shù)據(jù)庫(kù)、網(wǎng)絡(luò)、文件系統(tǒng)等外部環(huán)境或其它模塊。如果需要就用“測(cè)試替身”如Mock、Stub來(lái)模擬。而集成測(cè)試正是要檢驗(yàn)這些單元組合在一起與外部依賴(lài)交互時(shí)是否正確?；煜齼烧邥?huì)導(dǎo)致測(cè)試運(yùn)行慢、不穩(wěn)定且問(wèn)題定位困難。2.2. 單元測(cè)試由誰(shuí)負(fù)責(zé)打破“測(cè)試是QA的事”的誤區(qū)這是一個(gè)關(guān)鍵的文化問(wèn)題。答案很明確單元測(cè)試的主要編寫(xiě)責(zé)任在于開(kāi)發(fā)人員。原因如下知識(shí)獨(dú)占性開(kāi)發(fā)者最了解代碼的內(nèi)部邏輯、邊界條件和設(shè)計(jì)缺陷。讓測(cè)試人員來(lái)寫(xiě)他們需要花費(fèi)大量時(shí)間理解代碼效率低下且容易遺漏基于實(shí)現(xiàn)細(xì)節(jié)的用例。快速反饋閉環(huán)開(kāi)發(fā)者在編寫(xiě)功能代碼的同時(shí)或之后立即編寫(xiě)測(cè)試能夠立刻驗(yàn)證思路是否正確實(shí)現(xiàn)是否有偏差形成一個(gè)快速的“編碼-驗(yàn)證”閉環(huán)。如果交給另一個(gè)角色反饋周期被拉長(zhǎng)修復(fù)問(wèn)題的成本也更高。質(zhì)量?jī)?nèi)建將測(cè)試視為開(kāi)發(fā)過(guò)程不可或缺的一部分而不是事后檢查環(huán)節(jié)這有助于在源頭把控質(zhì)量。開(kāi)發(fā)者對(duì)自己代碼的質(zhì)量負(fù)責(zé)是天經(jīng)地義的事。那么測(cè)試工程師QA做什么他們專(zhuān)注于集成測(cè)試、端到端測(cè)試、系統(tǒng)測(cè)試和用戶驗(yàn)收測(cè)試。他們從用戶視角和系統(tǒng)整體出發(fā)驗(yàn)證業(yè)務(wù)流程是否通暢各個(gè)模塊組裝后能否協(xié)同工作。這是一種寶貴的、不同于開(kāi)發(fā)視角的補(bǔ)充而不是替代。在實(shí)際團(tuán)隊(duì)中特別是采用敏捷或DevOps模式的團(tuán)隊(duì)提倡“質(zhì)量是每個(gè)人的責(zé)任”。開(kāi)發(fā)人員保證單元測(cè)試的覆蓋率和質(zhì)量QA人員可能會(huì)參與評(píng)審單元測(cè)試用例確保其從業(yè)務(wù)角度覆蓋了重要場(chǎng)景并負(fù)責(zé)構(gòu)建更上層的自動(dòng)化測(cè)試。2.3. 評(píng)判好壞什么樣的單元測(cè)試才算合格寫(xiě)單元測(cè)試不是應(yīng)付差事寫(xiě)一堆脆弱的、重復(fù)的、難以理解的測(cè)試反而會(huì)成為負(fù)擔(dān)。一個(gè)好的單元測(cè)試應(yīng)該符合“FIRST”原則F - Fast快速測(cè)試必須運(yùn)行得快。一個(gè)龐大的單元測(cè)試套件如果運(yùn)行需要幾分鐘甚至幾小時(shí)開(kāi)發(fā)者就不會(huì)愿意頻繁運(yùn)行它從而失去了快速反饋的價(jià)值。理想情況下所有單元測(cè)試應(yīng)在幾秒到一兩分鐘內(nèi)跑完。I - Independent/Isolated獨(dú)立/隔離測(cè)試用例之間不應(yīng)該有依賴(lài)關(guān)系每個(gè)測(cè)試都能獨(dú)立運(yùn)行且運(yùn)行順序不影響結(jié)果。這樣才能精準(zhǔn)定位失敗點(diǎn)。R - Repeatable可重復(fù)測(cè)試在任何環(huán)境開(kāi)發(fā)機(jī)、CI服務(wù)器中重復(fù)運(yùn)行都應(yīng)該得到相同的結(jié)果。不能依賴(lài)未清理的數(shù)據(jù)庫(kù)狀態(tài)、特定的系統(tǒng)時(shí)間或隨機(jī)數(shù)除非被Mock。S - Self-validating自我驗(yàn)證測(cè)試的結(jié)果必須是二元的通過(guò)或失敗。不應(yīng)該需要人工去查看日志、對(duì)比文件來(lái)判斷測(cè)試是否通過(guò)。斷言Assert語(yǔ)句就是用來(lái)做這個(gè)的。T - Timely/Thorough及時(shí)/全面理想情況下測(cè)試應(yīng)該在產(chǎn)品代碼之前或同時(shí)編寫(xiě)TDD。同時(shí)測(cè)試需要全面覆蓋各種場(chǎng)景包括正常路徑、異常路徑和邊界條件。此外還要加上一條可讀性Readable。測(cè)試代碼本身也應(yīng)該是清晰、表達(dá)意圖的代碼。一個(gè)好的測(cè)試用例光看它的名字和結(jié)構(gòu)就能明白它在測(cè)試什么場(chǎng)景。例如test_calculate_discount_with_zero_rate就比test_discount_1要好得多。3. 單元測(cè)試核心實(shí)踐從工具選擇到用例設(shè)計(jì)3.1. 主流單元測(cè)試框架與工具選型工欲善其事必先利其器。選擇一套合適的測(cè)試框架和配套工具能讓編寫(xiě)測(cè)試事半功倍。不同語(yǔ)言生態(tài)有不同的選擇但核心組件類(lèi)似。1. 測(cè)試框架Test Framework這是骨架提供了編寫(xiě)測(cè)試用例、組織測(cè)試套件、運(yùn)行測(cè)試和生成報(bào)告的基礎(chǔ)能力。Java: JUnit (4/5) 是絕對(duì)主流特別是 JUnit 5 功能強(qiáng)大。TestNG 也有一定市場(chǎng)尤其在更復(fù)雜的測(cè)試配置需求場(chǎng)景。Python:unittest是標(biāo)準(zhǔn)庫(kù)內(nèi)置pytest因其簡(jiǎn)潔語(yǔ)法和強(qiáng)大插件生態(tài)已成為事實(shí)標(biāo)準(zhǔn)。JavaScript/TypeScript:Jest是目前最流行的“全家桶”式選擇開(kāi)箱即用。Mocha Chai (斷言庫(kù)) 的組合也非常靈活。對(duì)于 Vue 組件測(cè)試Vue Test Utils 或 Testing Library 是常用工具。C: Google Test (gtest) 應(yīng)用廣泛Catch2 以其僅需頭文件的簡(jiǎn)潔性受到歡迎。Go: 語(yǔ)言內(nèi)置testing包簡(jiǎn)單直接社區(qū)生態(tài)也圍繞其構(gòu)建。2. 斷言庫(kù)Assertion Library用于表達(dá)“期望結(jié)果”是測(cè)試邏輯的核心。很多框架內(nèi)置了斷言但獨(dú)立的斷言庫(kù)通常提供更豐富、更可讀的斷言方法。例如assert.equal(actual, expected)是基本款。而像expect(actual).toBe(expected)、assertThat(actual).isEqualTo(expected)這樣的鏈?zhǔn)秸{(diào)用表達(dá)力更強(qiáng)。3. 測(cè)試替身框架Mocking Framework用于創(chuàng)建“假對(duì)象”來(lái)模擬和替換真實(shí)的依賴(lài)項(xiàng)如數(shù)據(jù)庫(kù)訪問(wèn)層、網(wǎng)絡(luò)請(qǐng)求、第三方服務(wù)這是實(shí)現(xiàn)測(cè)試“隔離性”的關(guān)鍵。Java: Mockito 是王者EasyMock 和 PowerMock用于Mock靜態(tài)方法等也有使用。Python:unittest.mock(標(biāo)準(zhǔn)庫(kù)) 或pytest-mock插件。JavaScript: Jest 內(nèi)置了強(qiáng)大的 Mock 功能Sinon.js 也是一個(gè)專(zhuān)業(yè)的獨(dú)立庫(kù)。對(duì)于有狀態(tài)或及時(shí) UDF 和自定義算子例如在 Spark、Flink 或數(shù)據(jù)庫(kù)中的用戶自定義函數(shù)的測(cè)試Mock 尤為重要。你不需要啟動(dòng)一個(gè)完整的分布式計(jì)算環(huán)境而是 Mock 輸入數(shù)據(jù)的迭代器或上下文直接測(cè)試函數(shù)內(nèi)部的邏輯。4. 覆蓋率工具Coverage Tool用于衡量測(cè)試代碼對(duì)產(chǎn)品代碼的覆蓋程度是一個(gè)重要的量化指標(biāo)但切忌唯覆蓋率論。常用工具有 JaCoCo (Java)、Coverage.py/pytest-cov (Python)、Istanbul/Jest (JS) 等。如何選擇對(duì)于新項(xiàng)目直接選擇當(dāng)前語(yǔ)言生態(tài)下最主流、社區(qū)最活躍的框架組合。例如Python 新項(xiàng)目無(wú)腦選pytest就對(duì)了。對(duì)于老項(xiàng)目如果已有測(cè)試框架除非有難以忍受的痛點(diǎn)否則不建議輕易更換重構(gòu)測(cè)試的成本可能很高。3.2. 編寫(xiě)高質(zhì)量測(cè)試用例的“三段論”與模式一個(gè)結(jié)構(gòu)清晰的測(cè)試用例通常遵循Arrange-Act-Assert (AAA)模式我習(xí)慣叫它“三段論”Arrange (準(zhǔn)備)設(shè)置測(cè)試的前置條件。包括創(chuàng)建被測(cè)對(duì)象、準(zhǔn)備輸入數(shù)據(jù)、Mock依賴(lài)對(duì)象的行為。這部分的目標(biāo)是讓測(cè)試環(huán)境就緒。# 示例 (Python pytest) def test_apply_discount(): # Arrange product_price 100.0 discount_rate 0.2 # 20%折扣 calculator PriceCalculator() # 假設(shè) calculator 依賴(lài)一個(gè) TaxService我們 Mock 掉它 mock_tax_service Mock(specTaxService) mock_tax_service.get_tax_rate.return_value 0.1 calculator.tax_service mock_tax_serviceAct (執(zhí)行)調(diào)用被測(cè)方法得到實(shí)際結(jié)果。# Act final_price calculator.calculate_final_price(product_price, discount_rate)Assert (斷言)驗(yàn)證實(shí)際結(jié)果是否符合預(yù)期。這是測(cè)試的靈魂。# Assert # 計(jì)算期望值100 * (1-0.2) * (10.1) 88.0 expected_price 88.0 assert final_price pytest.approx(expected_price) # 使用近似比較避免浮點(diǎn)數(shù)精度問(wèn)題 # 同時(shí)驗(yàn)證 Mock 對(duì)象的交互行為如果重要的話 mock_tax_service.get_tax_rate.assert_called_once()這個(gè)模式強(qiáng)迫你思考測(cè)試的每個(gè)階段讓測(cè)試代碼清晰可讀。一個(gè)測(cè)試方法最好只測(cè)試一個(gè)具體場(chǎng)景或行為遵循“單一職責(zé)原則”。3.3. 測(cè)試什么用例設(shè)計(jì)的核心思維寫(xiě)測(cè)試最難的不是語(yǔ)法而是“測(cè)什么”。以下是幾種經(jīng)典且實(shí)用的測(cè)試用例設(shè)計(jì)思路正常路徑 (Happy Path)最常用、最直接的輸入驗(yàn)證核心功能是否工作。這是最基本的。邊界條件 (Boundary Conditions)這是 Bug 的溫床也是測(cè)試的重點(diǎn)。例如對(duì)于數(shù)值最大值、最小值、剛好大于/小于邊界值、零。對(duì)于集合空集合、只有一個(gè)元素的集合、滿容量的集合。對(duì)于字符串空串、非常長(zhǎng)的串、包含特殊字符的串。異常路徑 (Sad Path/Error Conditions)輸入非法數(shù)據(jù)或處于異常狀態(tài)時(shí)程序的行為是否符合預(yù)期是拋出特定的異常還是返回錯(cuò)誤碼例如傳入None/null傳入負(fù)數(shù)價(jià)格傳入不存在的ID。狀態(tài)驗(yàn)證 vs. 行為驗(yàn)證狀態(tài)驗(yàn)證檢查方法執(zhí)行后對(duì)象的狀態(tài)屬性值是否改變正確。這是最常用的。行為驗(yàn)證檢查方法是否按預(yù)期調(diào)用了其他對(duì)象的方法。這在測(cè)試對(duì)象間協(xié)作時(shí)很重要通常通過(guò) Mock 框架來(lái)驗(yàn)證。例如驗(yàn)證“保存訂單”方法是否確實(shí)調(diào)用了orderRepository.save()一次。對(duì)于前面提到的Vue 組件單元測(cè)試思路是類(lèi)似的但關(guān)注點(diǎn)不同。你測(cè)試的不是業(yè)務(wù)邏輯函數(shù)而是組件的渲染輸出、用戶交互和事件響應(yīng)。使用vue/test-utils你可以Arrange使用mount或shallowMount掛載組件可能傳入特定的props和data。Act模擬用戶操作如wrapper.find(button).trigger(click)或直接調(diào)用組件實(shí)例上的方法。Assert驗(yàn)證渲染的 HTML 是否包含特定內(nèi)容 (wrapper.text()) 驗(yàn)證emit的事件是否正確或者驗(yàn)證組件內(nèi)部數(shù)據(jù)是否變化。遇到vue單元測(cè)試報(bào)錯(cuò)常見(jiàn)原因有未正確配置測(cè)試環(huán)境如缺少vue/babel-preset-app等轉(zhuǎn)換器、在測(cè)試中使用了瀏覽器特有的 API如window、document而未做模擬、組件依賴(lài)了未注入的 Vuex store 或 Router。解決之道是仔細(xì)閱讀錯(cuò)誤堆棧并確保測(cè)試環(huán)境是隔離的、純 Node.js 的。4. 高級(jí)場(chǎng)景與實(shí)戰(zhàn)避坑指南4.1. 復(fù)雜場(chǎng)景的單元測(cè)試策略當(dāng)代碼涉及數(shù)據(jù)庫(kù)、網(wǎng)絡(luò)、文件、時(shí)間等外部依賴(lài)時(shí)測(cè)試會(huì)變得復(fù)雜。核心策略是隔離與模擬。測(cè)試數(shù)據(jù)庫(kù)操作絕對(duì)不要連接真實(shí)數(shù)據(jù)庫(kù)跑單元測(cè)試。有兩種主流方法使用內(nèi)存數(shù)據(jù)庫(kù)如 H2 (Java)、SQLite (Python/其他)。速度快但和真實(shí)數(shù)據(jù)庫(kù)仍有差異主要測(cè)試 SQL 或 ORM 映射邏輯。Mock 數(shù)據(jù)訪問(wèn)層這是更純粹、更推薦的做法。Mock 掉你的Repository或DAO類(lèi)讓它返回你預(yù)設(shè)的數(shù)據(jù)。這樣測(cè)試完全聚焦于業(yè)務(wù)邏輯層速度極快。// Java Mockito 示例 Test public void testGetUserById() { // Arrange User mockUser new User(1, Alice); UserRepository mockRepo mock(UserRepository.class); when(mockRepo.findById(1)).thenReturn(Optional.of(mockUser)); UserService service new UserService(mockRepo); // Act User result service.getUserProfile(1); // Assert assertEquals(Alice, result.getName()); verify(mockRepo).findById(1); // 驗(yàn)證交互 }測(cè)試異步代碼現(xiàn)代應(yīng)用充滿異步操作。測(cè)試框架通常提供支持。Jest (JS)測(cè)試異步函數(shù)可以返回 Promise或使用async/await。pytest (Python)使用pytest-asyncio插件來(lái)測(cè)試asyncio代碼。關(guān)鍵點(diǎn)是測(cè)試框架需要知道何時(shí)你的異步操作完成以便進(jìn)行斷言。測(cè)試有狀態(tài)或及時(shí) UDF 和自定義算子這是大數(shù)據(jù)處理如 Spark、Flink或數(shù)據(jù)庫(kù)中的常見(jiàn)需求。核心思想將 UDF/算子的邏輯與運(yùn)行時(shí)環(huán)境分離。提取出純函數(shù)邏輯部分進(jìn)行單元測(cè)試。方法創(chuàng)建模擬的輸入數(shù)據(jù)迭代器如一個(gè)簡(jiǎn)單的 List模擬運(yùn)行時(shí)上下文Context然后直接調(diào)用你的 UDF 函數(shù)驗(yàn)證其輸出。對(duì)于涉及狀態(tài)如累加、窗口的算子需要模擬狀態(tài)后端但測(cè)試重點(diǎn)仍是邏輯轉(zhuǎn)換的正確性。工具像 Spark 和 Flink 社區(qū)都提供了一些測(cè)試工具類(lèi)如TestHarness可以幫助你構(gòu)建微型的測(cè)試環(huán)境。4.2. 測(cè)試驅(qū)動(dòng)開(kāi)發(fā)TDD的簡(jiǎn)要實(shí)踐TDD 是一種“先寫(xiě)測(cè)試再寫(xiě)實(shí)現(xiàn)”的開(kāi)發(fā)方法遵循“紅-綠-重構(gòu)”循環(huán)紅針對(duì)一個(gè)未實(shí)現(xiàn)的小功能先寫(xiě)一個(gè)會(huì)失敗的測(cè)試紅。綠編寫(xiě)最少、最簡(jiǎn)單的代碼讓這個(gè)測(cè)試通過(guò)綠。重構(gòu)在測(cè)試通過(guò)的保護(hù)下優(yōu)化代碼結(jié)構(gòu)消除重復(fù)提升設(shè)計(jì)。TDD 能極大地提升代碼的可測(cè)試性和設(shè)計(jì)質(zhì)量因?yàn)樗仁鼓阍诰幋a前就從調(diào)用者角度思考接口。但它也有學(xué)習(xí)曲線對(duì)復(fù)雜算法或探索性任務(wù)可能不適用。初學(xué)者可以從一個(gè)小功能、一個(gè)工具類(lèi)開(kāi)始嘗試不必強(qiáng)求全程 TDD。4.3. 常見(jiàn)陷阱與最佳實(shí)踐心得陷阱1測(cè)試過(guò)于脆弱測(cè)試與實(shí)現(xiàn)細(xì)節(jié)如私有方法、內(nèi)部狀態(tài)順序綁定過(guò)緊。一旦實(shí)現(xiàn)重構(gòu)即使行為不變測(cè)試就大量失敗。這嚴(yán)重打擊團(tuán)隊(duì)重構(gòu)的積極性。對(duì)策測(cè)試公共接口和行為而非內(nèi)部實(shí)現(xiàn)。關(guān)注“輸入輸出”而不是“怎么做的”。陷阱2過(guò)度使用 MockMock 是利器但濫用會(huì)帶來(lái)問(wèn)題。如果你 Mock 了被測(cè)單元的所有依賴(lài)那實(shí)際上你只測(cè)試了被測(cè)單元的一小部分邏輯而它與其他組件的集成問(wèn)題被掩蓋了。對(duì)策遵循“經(jīng)典派”與“倫敦派”的平衡。對(duì)于外部服務(wù)數(shù)據(jù)庫(kù)、HTTP API堅(jiān)決 Mock。對(duì)于系統(tǒng)內(nèi)緊耦合的、共同演進(jìn)的組件可以考慮使用真實(shí)對(duì)象或 Stub。區(qū)分“協(xié)作對(duì)象”和“依賴(lài)服務(wù)”。陷阱3追求100%覆蓋率魔咒代碼覆蓋率是一個(gè)有用的指標(biāo)但不是目標(biāo)。達(dá)到80%的覆蓋率可能只需要20%的努力而為了最后20%的覆蓋率如 getter/setter、簡(jiǎn)單的框架配置代碼可能需要80%的努力且價(jià)值很低。對(duì)策關(guān)注關(guān)鍵邏輯的覆蓋率。工具生成的覆蓋率報(bào)告要結(jié)合人工審查重點(diǎn)看核心業(yè)務(wù)邏輯、條件分支是否被覆蓋。不要為了覆蓋率而寫(xiě)無(wú)意義的測(cè)試。陷阱4測(cè)試代碼本身質(zhì)量低下測(cè)試代碼也是代碼也需要維護(hù)。如果測(cè)試代碼冗長(zhǎng)、重復(fù)、難以理解它就會(huì)成為債務(wù)。對(duì)策使用 Setup/Teardown利用框架提供的BeforeEach、setUp等方法提取公共的初始化邏輯。創(chuàng)建測(cè)試工具函數(shù)/工廠對(duì)于復(fù)雜的對(duì)象構(gòu)建創(chuàng)建工廠方法如createTestUser()。保持測(cè)試獨(dú)立每個(gè)測(cè)試自己準(zhǔn)備數(shù)據(jù)不依賴(lài)其他測(cè)試留下的全局狀態(tài)。給測(cè)試起好名字測(cè)試方法名應(yīng)該清晰地表達(dá)其意圖例如should_throw_exception_when_input_is_negative。個(gè)人心得單元測(cè)試不是銀彈它不能發(fā)現(xiàn)所有 Bug尤其是集成和系統(tǒng)層面的問(wèn)題。但它是一道極其重要的、成本最低的早期防線。培養(yǎng)寫(xiě)測(cè)試的習(xí)慣就像健身開(kāi)始會(huì)覺(jué)得是負(fù)擔(dān)但一旦形成肌肉記憶并嘗到它帶來(lái)的“重構(gòu)自由”和“發(fā)布信心”的甜頭就再也回不去了。對(duì)于遺留代碼沒(méi)有測(cè)試的代碼不要試圖一次性補(bǔ)全所有測(cè)試。在修改它或修復(fù)其 Bug 之前先為相關(guān)部分加上測(cè)試讓這些測(cè)試成為你修改時(shí)的“安全帶”這是一種安全且有效的策略。