作者 | 王浩(光酒)

什么是單元測(cè)試

《單元測(cè)試的藝術(shù)》中對(duì)單元測(cè)試的定義：

一個(gè)單元測(cè)試是一段自動(dòng)化的代碼，這段代碼調(diào)用被測(cè)試的工作單元，之后對(duì)這個(gè)單元的單個(gè)最終結(jié)果的某些假設(shè)進(jìn)行校驗(yàn)。單元測(cè)試幾乎都是用單元測(cè)試框架編寫的；只要產(chǎn)品代碼不發(fā)生變化，單元測(cè)試的結(jié)果是穩(wěn)定的。

為什么需要單元測(cè)試

在我看來，單元測(cè)試的意義可以總結(jié)如下三點(diǎn)：

• 單元測(cè)試是保證你寫的代碼是你想要的結(jié)果的最有效辦法
• 單元測(cè)試幫我們塑造設(shè)計(jì)
• 單元測(cè)試是最好的文檔之一?

單元測(cè)試描述了代碼的預(yù)期行為，可以最有效地保證代碼正確運(yùn)行，減少代碼缺陷；由于單元規(guī)模較小，當(dāng)因?yàn)榇a變更出現(xiàn)問題的時(shí)候，可以幫助我們快速定位問題；有單元測(cè)試覆蓋的代碼，讓我們更有信心，敢于放心做代碼重構(gòu)；寫單元測(cè)試的過程往往伴隨著代碼重構(gòu)，如果發(fā)現(xiàn)一段代碼單元測(cè)試很難寫，就需要反思我們的設(shè)計(jì)，進(jìn)而重構(gòu)促進(jìn)代碼設(shè)計(jì)的優(yōu)化，幫助我們塑造設(shè)計(jì)；同時(shí)單元測(cè)試也是一個(gè)最佳的、自動(dòng)化的、可執(zhí)行的文檔；沒有單測(cè)覆蓋的代碼，是很難被維護(hù)的。

什么是有效的單元測(cè)試

可讀、可維護(hù)、可信賴、快速執(zhí)行！《單元測(cè)試的藝術(shù)》中描述優(yōu)秀單元的特性：

• 它應(yīng)該是自動(dòng)化的，可重復(fù)執(zhí)行；
• 它應(yīng)該很容易實(shí)現(xiàn)；
• 它應(yīng)該第二天還有意義；
• 任何人都應(yīng)該能一鍵運(yùn)行它；
• 它應(yīng)該運(yùn)行速度很快；
• 它的結(jié)果應(yīng)該是穩(wěn)定的（如果運(yùn)行之間沒有進(jìn)行修改的話，多次運(yùn)行一個(gè)測(cè)試應(yīng)該總是
• 返回同樣的結(jié)果）;
• 它應(yīng)該能完全控制被測(cè)試的單元；
• 它應(yīng)該是完全隔離的（獨(dú)立于其他測(cè)試的運(yùn)行)；
• 如果它失敗了，我們應(yīng)該很容易發(fā)現(xiàn)什么是期待的結(jié)果，進(jìn)而定位問題所在。

可讀性

“一般程序員寫得出計(jì)算機(jī)能讀懂的代碼。優(yōu)秀程序員寫得出人能讀懂的代碼” — 馬丁·福勒可讀的代碼才是可維護(hù)的；難以閱讀和理解的測(cè)試用例，最終的結(jié)果就是刪掉它，因?yàn)榫S護(hù)成本過高?？勺x性高于純粹的性能。

可維護(hù)性

團(tuán)隊(duì)內(nèi)使用一套范式的結(jié)構(gòu)，有助于使之更好用，快速定位問題；消滅代碼中的壞味道。

可信賴

可信賴的含義：

• 測(cè)試可重復(fù)；
• 測(cè)試與依賴環(huán)境隔離；
• 只測(cè)試不進(jìn)行驗(yàn)證是不可靠的測(cè)試；
• 在測(cè)試類中不要依賴與測(cè)試的順序；
• 測(cè)試的結(jié)果是精準(zhǔn)的：校驗(yàn)的精準(zhǔn)以及錯(cuò)誤問題的精準(zhǔn)定位；

快速執(zhí)行

保證單測(cè)快速執(zhí)行，縮短反饋時(shí)長(zhǎng)；

為什么有效的單元測(cè)試如此重要

無效的單元測(cè)試是沒有意義的，反而會(huì)增加維護(hù)成本，最終導(dǎo)致單元測(cè)試的失??！

如上圖所示，坐標(biāo)中任意一個(gè)點(diǎn)，其與橫縱坐標(biāo)垂直線所形成的矩形面積代表CI為團(tuán)隊(duì)帶來的價(jià)值，那么在我看來有兩個(gè)關(guān)鍵的因素：橫坐標(biāo)是單元測(cè)試的基礎(chǔ)能力建設(shè)，縱坐標(biāo)則是有效的單元測(cè)試；沒有有效的單元測(cè)試，基礎(chǔ)能力做出花來也毫無意義！完善的基礎(chǔ)能力同時(shí)也幫助我們更低成本的寫出有效的單元測(cè)試。

如何寫有效的單元測(cè)試

我們以Flutter為例，來一起討論如何寫有效的單元測(cè)試；

使用測(cè)試框架

Flutter官方提供的測(cè)試框架：

• flutter_test
• integration_test

統(tǒng)一的編碼約定

不論是AAA（Arrange-Act-Assert）還是GWT（Given-When-Then），統(tǒng)一的編碼約定幫助保證測(cè)試代碼的可讀性、可維護(hù)性。

使用測(cè)試替身

測(cè)試替身幫助我們隔離被測(cè)試代碼，加速執(zhí)行速度，保證測(cè)試代碼是可信賴的；

• Dummy：一種什么也不做的實(shí)現(xiàn)方式。接口中的每個(gè)方法什么也不做，如果方法有返回值，返回的值盡量接近null或者0。
• Stub：Dummy的一種，Stub的函數(shù)并不返回null或0，而是返回能推動(dòng)函數(shù)沿預(yù)定路徑被測(cè)試的值。
• Spy：Stub的一種，它返回測(cè)試所需的特定值，推動(dòng)系統(tǒng)沿著我們期望的路徑前行。然而，Spy能記住對(duì)它所做的事，并允許測(cè)試詢問。
• Mock：Spy的一種，它返回測(cè)試所需的特定值，推動(dòng)系統(tǒng)沿著我們期望的路徑前行，而且還會(huì)記住對(duì)它所做的事。不過，Mock還知道我們的預(yù)期，基于這些預(yù)期，判斷測(cè)試是否通過；換而言之，Mock中寫明了測(cè)試斷言。
• Fake：Fake是一種模擬器，它實(shí)現(xiàn)基礎(chǔ)業(yè)務(wù)規(guī)則，這樣測(cè)試就能要求該Fake按需要的路徑執(zhí)行。

一個(gè)測(cè)試應(yīng)當(dāng)只檢查一件事

明確測(cè)試意圖，一旦出錯(cuò)可以精準(zhǔn)定位問題；

一個(gè)測(cè)試只有一個(gè)模擬對(duì)象

避免過多模擬對(duì)象，一個(gè)測(cè)試用例的校驗(yàn)內(nèi)容盡量簡(jiǎn)單；

避免冗余測(cè)試

冗余測(cè)試會(huì)提高維護(hù)成本；

避免條件邏輯

條件邏輯會(huì)讓你的單元測(cè)試更難以維護(hù)，出問題不容易排查，不夠精準(zhǔn)；

單測(cè)需要確定性

避免脆弱測(cè)試，Mock不確定的依賴：時(shí)間、隨機(jī)數(shù)、并發(fā)性、基礎(chǔ)設(shè)施、現(xiàn)存數(shù)據(jù)、持久化、網(wǎng)絡(luò)等等；

測(cè)試快速執(zhí)行

避免sleep等操作，導(dǎo)致測(cè)試執(zhí)行緩慢；

避免過度指定

對(duì)于過度指定的討論，其核心問題就是要我們判斷哪些是單元測(cè)試應(yīng)該覆蓋的，哪些是應(yīng)該留給其他測(cè)試手段的。如果一個(gè)場(chǎng)景，單元測(cè)試覆蓋之后，導(dǎo)致經(jīng)常單測(cè)失敗，需要不斷更新維護(hù)，那就可以考慮不做單元測(cè)試覆蓋。像素完美是一個(gè)典型的、經(jīng)常拿出來討論的例子，F(xiàn)lutter的Golden Test就是一個(gè)golden master testing的例子；《有效的單元測(cè)試》中關(guān)于像素完美的討論：

像素完美：顧名思義，是一種特定于圖形和圖像生成的測(cè)試壞味道。它混雜了魔法數(shù)字和基本斷言，使得測(cè)試極難閱讀也極其脆弱。

這種測(cè)試幾乎無法閱讀，因?yàn)榧词箿y(cè)試在語義上是處于高層概念的，卻仍然會(huì)針對(duì)硬編碼的底層細(xì)節(jié)例如像素坐標(biāo)和顏色來進(jìn)行斷言。指定坐標(biāo)上的像素是黑還是白，與兩個(gè)圖形是否相連或堆疊的概念是有區(qū)別的。

這種測(cè)試極其脆弱，因?yàn)榧词购苄〉暮筒幌嚓P(guān)的輸入變化——是否是另一個(gè)圖像，或圖形對(duì)象的渲染方式——都足以影響輸出、打破測(cè)試，誰讓你非要精確地檢查像素坐標(biāo)和顏色呢。同樣的問題在采用golden master技術(shù)時(shí)也會(huì)遇到，其做法是事先將圖像錄制下來，并手工檢查其正確性，以后再進(jìn)行測(cè)試時(shí)就將渲染出的圖像與之進(jìn)行比對(duì)。

這些可不是我們?cè)敢馊ゾS護(hù)的測(cè)試。我們不希望帶著這種脆弱的精確度去編寫測(cè)試，而是使用模糊匹配和智能算法來代替繁瑣的數(shù)值比較。

對(duì)于特定場(chǎng)景，Golden Test是一個(gè)非常有效的手段，但需要非常謹(jǐn)慎的評(píng)估；慎用Golden Test！

不要寫永不失敗的測(cè)試，不要寫沒有校驗(yàn)的測(cè)試

單測(cè)需要對(duì)明確的邏輯校驗(yàn)，永不失敗的測(cè)試或者沒有校驗(yàn)的測(cè)試是不可信賴的。

測(cè)試不要名不副實(shí)

避免測(cè)試的描述與測(cè)試內(nèi)容不符；測(cè)試結(jié)果必須精準(zhǔn)；測(cè)試該失敗的時(shí)候一定要失??！

測(cè)試私有或者受保護(hù)的方法

解決思路：

• 將方法變成公共方法；
• 將方法抽取到新類；
• 將方法變成靜態(tài)方法；
• 將方法成為測(cè)試可見方法；

避免強(qiáng)制的測(cè)試順序

依賴測(cè)試順序?qū)е聹y(cè)試可靠性變得脆弱，未來維護(hù)成本變高；

清理測(cè)試環(huán)境

在teardown階段清理測(cè)試環(huán)境，例如還原全局的Config、清理創(chuàng)建的文件目錄等等；

統(tǒng)一的單測(cè)命名、變量命名

統(tǒng)一的單測(cè)命名可以提高可讀性、可維護(hù)性；

使用有意義的斷言

斷言的錯(cuò)誤信息要有意義，出現(xiàn)問題能夠明確錯(cuò)誤的原因；

把單元測(cè)試視為“一等公民”

測(cè)試用例應(yīng)該被視為“一等公民”：同樣需要代碼評(píng)審，同樣需要代碼質(zhì)量檢查，確保單元測(cè)試的有效性；單元測(cè)試代碼評(píng)審的過程，也是團(tuán)隊(duì)同學(xué)互相學(xué)習(xí)的過程，沉淀最佳實(shí)踐的過程。

加速執(zhí)行速度

日常對(duì)單測(cè)執(zhí)行時(shí)間進(jìn)行監(jiān)控，對(duì)測(cè)試進(jìn)行性能分析，優(yōu)化執(zhí)行時(shí)間過長(zhǎng)的測(cè)試用例。

測(cè)試金字塔

測(cè)試金字塔是Mike Cohn在他的著作《Succeeding with Agile》一書中提出了這個(gè)概念。測(cè)試金字塔是一個(gè)比喻，它告訴我們要把軟件測(cè)試按照不同粒度來分組。它也告訴我們每個(gè)組應(yīng)該有多少測(cè)試。

為了維持金字塔形狀，一個(gè)健康、快速、可維護(hù)的測(cè)試組合應(yīng)該是這樣的：寫許多小而快的單元測(cè)試。適當(dāng)寫一些更粗粒度的測(cè)試，寫很少高層次的端到端測(cè)試。注意不要讓你的測(cè)試變成冰淇淋或者沙漏那樣子，這對(duì)維護(hù)來說將是一個(gè)噩夢(mèng)，并且跑一遍也需要太多時(shí)間。

避免測(cè)試重復(fù)

在實(shí)現(xiàn)測(cè)試金字塔時(shí)，你也應(yīng)該牢記這兩條基本法則：

如果一個(gè)更高層級(jí)的測(cè)試發(fā)現(xiàn)了一個(gè)錯(cuò)誤，并且底層測(cè)試全都通過了，那么你應(yīng)該寫一個(gè)低層級(jí)測(cè)試去覆蓋這個(gè)錯(cuò)誤；

竭盡所能把測(cè)試往金字塔下層趕；

如果你已經(jīng)在低層級(jí)測(cè)試?yán)锔采w了所有情況，那么再維護(hù)一個(gè)高層級(jí)的測(cè)試就沒有必要了。警惕沉沒成本的思維陷阱，果斷摁下刪除鍵。沒有理由在不再提供價(jià)值的測(cè)試上浪費(fèi)寶貴時(shí)間。

補(bǔ)充單元測(cè)試應(yīng)該從哪里開始

單元測(cè)試應(yīng)該及時(shí)編寫，就算沒有實(shí)踐TDD，也應(yīng)該在代碼實(shí)現(xiàn)之后盡快編寫單元測(cè)試，避免寫出不可測(cè)試的代碼，也可以讓bug盡早暴露；但很不幸的，我們很多時(shí)候在剛開始卓越工程，推廣單元測(cè)試的時(shí)候，不得不面對(duì)補(bǔ)充單元測(cè)試的情況；這絕對(duì)是一個(gè)有挑戰(zhàn)的事情。補(bǔ)充單元測(cè)試應(yīng)該從哪里開始？參考測(cè)試金字塔，對(duì)于基礎(chǔ)組件庫(kù)來說，可以根據(jù)具體情況來定；對(duì)于業(yè)務(wù)庫(kù)來說，第一步建議從金字塔頂端的測(cè)試：

• 優(yōu)先覆蓋回歸測(cè)試用例中P0級(jí)別的用例；
• 避免過度指定的端到端測(cè)試；
• 適當(dāng)?shù)钠跫s測(cè)試；

接下來，從金字塔中間層開始，不斷向上、向下補(bǔ)充；

可測(cè)試的設(shè)計(jì)

應(yīng)當(dāng)容易、快速地為一段代碼編寫單元測(cè)試；可測(cè)試的設(shè)計(jì)，使我們寫出模塊化的設(shè)計(jì)；

行動(dòng)指南

為了寫出可測(cè)試的代碼，需要注意以下幾點(diǎn)：

• 避免復(fù)雜的私有方法；
• 避免final方法；
• 避免static方法；
• 使用new要當(dāng)心；
• 避免構(gòu)造函數(shù)中包含邏輯；
• 避免單例；
• 組合優(yōu)于繼承；
• 避免服務(wù)查找；
• 基于接口的設(shè)計(jì)；

可測(cè)試的代碼是否違背了SOLID中的開閉原則？

可測(cè)試的代碼設(shè)計(jì)，有的時(shí)候需要避免復(fù)雜的私有方法或者受保護(hù)的方法，因?yàn)檫@些意味著不可測(cè)試；這樣的話是不是意味著可測(cè)試的設(shè)計(jì)違反了開閉原則呢？在代碼重構(gòu)的時(shí)候，可以認(rèn)為給對(duì)象模型增加了另外一種最終用戶——測(cè)試用戶。另外如果一部分代碼實(shí)在不希望暴露，也可以使用@visibleForTesting 修飾；

單元測(cè)試與重構(gòu)

寫單元測(cè)試的過程往往伴隨著重構(gòu)；代碼重構(gòu)同樣需要單元測(cè)試保證代碼正確運(yùn)行。重構(gòu)需要遵守的紀(jì)律：無測(cè)試重構(gòu)無意義，頻繁重構(gòu)、果斷重構(gòu)、堅(jiān)決重構(gòu)；

持續(xù)重構(gòu)

將麻煩扼殺在搖籃；

果斷重構(gòu)

敏捷編程的名言之一。規(guī)則很簡(jiǎn)單：重構(gòu)時(shí)要勇敢。勇敢嘗試，勇敢修改，不用害怕代碼。

讓測(cè)試始終能通過

建一個(gè)綠色安全區(qū)，不允許破窗出現(xiàn)。

留條出路

倉(cāng)庫(kù)打好tag，以便在需要的時(shí)候能夠回滾。

可測(cè)試的代碼

可測(cè)試的代碼就是解耦了的代碼；可測(cè)試的代碼幫助我們實(shí)現(xiàn)更好的抽象。

做不到TDD，可以做到測(cè)試先行

下圖是遵循TDD三大法則的實(shí)踐過程；TDD很強(qiáng)大，但不一定適用所有的團(tuán)隊(duì)，推廣難度很大，學(xué)習(xí)曲線很高。

TDD事實(shí)上由兩個(gè)方面組成：測(cè)試先行，以及演進(jìn)式設(shè)計(jì)；測(cè)試先行是非常重要的工程實(shí)踐，做不到TDD，可以做到測(cè)試先行。在Kent Beck的經(jīng)典名著《解析極限編程》中，提到：盡早測(cè)試，經(jīng)常測(cè)試，自動(dòng)測(cè)試！測(cè)試先行的本質(zhì)能力要求是接口的設(shè)計(jì)能力——能否清晰的定義出設(shè)計(jì)單元的邊界。

如何理解單元測(cè)試代碼覆蓋率

不要把它們變成管理的指標(biāo)。這就是你使用覆蓋率數(shù)字的目的：使用它們作為衡量標(biāo)準(zhǔn)來幫助你改進(jìn)，而不是用它們作為懲罰團(tuán)隊(duì)和使構(gòu)建失敗的棍棒。 ——《匠藝整潔之道》

代碼覆蓋率的一大忌諱：為了追求代碼覆蓋率，只測(cè)試不進(jìn)行驗(yàn)證；一味追求代碼覆蓋率，往往寫出無效的單元測(cè)試，額外增加了維護(hù)成本，最終不得不放棄以失敗告終。與其追求代碼覆蓋率，不如將重點(diǎn)關(guān)注在確保寫出有意義的測(cè)試。

沉淀最佳實(shí)踐

必須承認(rèn)單元測(cè)試有一定的成本，成本曲線來看，前期比較高；恰恰是這前期的門檻，讓很多人望而卻步。在團(tuán)隊(duì)內(nèi)推廣的時(shí)候，最難的就是寫出第一個(gè)單元測(cè)試；我們需要沉淀最佳實(shí)踐，幫助降低寫單元測(cè)試的成本，讓我們更容易地寫出有效的單元測(cè)試。我覺得沉淀最佳實(shí)踐最好的方法，就是Code Review；正如我們前面所說的，要把單元測(cè)試當(dāng)成是“一定公民”，在Code Review的過程中，互相學(xué)習(xí)、分享最佳實(shí)踐，消除無效的單元測(cè)試。

隔離單元測(cè)試與集成測(cè)試

集成測(cè)試是對(duì)一個(gè)工作單元進(jìn)行的測(cè)試，這個(gè)測(cè)試對(duì)被測(cè)試的工作單元沒有完全的控制，并使用該工作單元一個(gè)或多個(gè)真實(shí)依賴，例如時(shí)間、網(wǎng)絡(luò)、數(shù)據(jù)庫(kù)、線程或隨機(jī)數(shù)生成器等。

任何測(cè)試，如果它的運(yùn)行速度不快，結(jié)果不穩(wěn)定，或者要用到被測(cè)試單元的一個(gè)或多個(gè)真實(shí)依賴，就是集成測(cè)試。在日常開發(fā)過程，我們需要建一個(gè)綠色安全區(qū)：?jiǎn)卧獪y(cè)試與集成測(cè)試隔離；集成測(cè)試不夠穩(wěn)定，運(yùn)行時(shí)間長(zhǎng)等問題，如果不做隔離，日常開發(fā)浪費(fèi)時(shí)間和精力維護(hù)，最后導(dǎo)致開發(fā)人員不再信任測(cè)試。

單元測(cè)試與ABTest

單元測(cè)試與ABTest有什么關(guān)系嗎？事實(shí)上沒有什么關(guān)系。但一定程度程度上，它們本質(zhì)是相同的，都是保障線上代碼質(zhì)量（當(dāng)然單測(cè)的成本，對(duì)于基建、開發(fā)者的能力的要求更高）；在日常開發(fā)中，經(jīng)常主動(dòng)為新的代碼邏輯增加AB開關(guān)，一旦線上出問題留一條后路；發(fā)生問題的時(shí)候往往感慨AB開關(guān)救我一命；單元測(cè)試可以讓問題左移，防止問題上線，同樣是一道保護(hù)；如果有一天團(tuán)隊(duì)同學(xué)愿意主動(dòng)增加單元測(cè)試來保護(hù)自己的代碼，那么單元測(cè)試這件事就算比較成功了。

寫在最后

從軟件工程到卓越工程，單元測(cè)試從可選變成了必要；想要實(shí)現(xiàn)主干開發(fā)、大庫(kù)模式，單元測(cè)試是前提條件。關(guān)于單元測(cè)試這件事，我覺得最重要永遠(yuǎn)是寫單元測(cè)試的人，優(yōu)秀的團(tuán)隊(duì)文化非常重要，沒有什么能夠真正衡量單元測(cè)試做的好壞，有的只是程序員的職業(yè)操守。我們花了很大的篇幅討論有效單元測(cè)試的重要性以及如何寫出有效的單元測(cè)試，不得不承認(rèn)單元測(cè)試有一定的成本，真正實(shí)踐依然需要很多的路要走，需要我們?cè)趯?shí)踐中定義好單元測(cè)試的邊界，找到最適合團(tuán)隊(duì)的最佳實(shí)踐。

參考文檔

• 《單元測(cè)試的藝術(shù)》
• 《有效的單元測(cè)試》
• 《Succeeding with Agile》
• 《匠藝整潔之道》
• The Test Pyramid：https://martinfowler.com/articles/practical-test-pyramid.html
• Software Engineering at Google：https://qiangmzsx.github.io/Software-Engineering-at-Google/#/zh-cn/Chapter-12_Unit_Testing/Chapter-12_Unit_Testing