單元測試，只是測試嗎？
推廣單元測試，僅僅達到單測覆蓋率是遠遠不夠的，我們還要學習寫"易于測試"的代碼，以及"好"的測試，這樣才能讓單測真正發(fā)揮作用。本文將分享作者關(guān)于單元測試的思考與實踐。
首先我就來回答一下標題提出的問題：單元測試除了是一種測試手段外，更是一種改善代碼設計的工具，容易寫單測的代碼往往也具有更加良好的設計。
因而是任何自動化測試工具都無法取代的。
當然，這里也不是把自動化測試工具給一棍子打死，自動化測試工具也有自己的使用場景，比如測試遺留代碼，做長鏈路測試等等。
這里需要強調(diào)一下 "工具" 屬性，工具能放大人的智力或者體力，讓干活的時候不會這么累，比如你去種樹帶把鏟子，你肯定不會把鏟子當成負擔的，因為他是你種樹的工具，你寫 Java，肯定不會因為 IDEA 啟動時間長，就把它當成一種負擔，因為 IDEA 也是你寫 Java 的一個工具，很多人把寫單測當成一種負擔，往往就是沒有意識到"單測"是一種工具，單純把他當成一種測試。
一 品味篇
在品味篇，一起看看什么樣的代碼才是易于單測的。
Mock 工具的使用——毒藥還是解藥
你可能立刻就會產(chǎn)生和程序員小 A 類似的疑惑："無論代碼寫成什么樣，通過 Mockito 和 PowerMock 肯定都是能寫出單測來?所以通過單測真的改善代碼結(jié)構(gòu)嗎?"。
實際上，大量使用 Mock 工具的單測相當于買櫝還珠，只具備測試的能力而無法幫助代碼設計。
商店系統(tǒng)案例
以一段非常簡單的程序為例，假設這是一個商店系統(tǒng)，里面有一個買面包的方法，里面會調(diào)用銀行提供的信用卡服務 creditCardService 來扣除傳入的信用卡的錢。這段程序如果使用 Mockito 的話，估計你很快就能寫出測試了，只需要把 creditCardService 給 Mock 掉，然后驗證它傳入的參數(shù)就可以了。
如果總是像上面這樣思考的話，單測對于你改善代碼設計就沒什么幫助了。我們在給代碼寫單測的時候不應該上來就思考用什么樣的工具來測試代碼，而是應該思考如何重構(gòu)代碼，才能讓代碼變得更加容易測試。
還是上面這段代碼，我們換個角度，思考下如何重構(gòu)代碼，才能讓這段邏輯不需要 mock 就能測試?
返回一個執(zhí)行計劃，而不是立即執(zhí)行外部調(diào)用
上層拿到一個 Payment 實體后，可以選擇立即執(zhí)行，或者稍后統(tǒng)一執(zhí)行
其實非常簡單的一個辦法是，返回一個計劃，而不是立即就執(zhí)行外部調(diào)用，比如這里我們可以抽象出一個 Payment 實體，表示從銀行卡里劃了多少錢，外部拿到 Payment 實體后再決定是立即把錢劃掉，還是稍后把錢統(tǒng)一劃掉。此時這一段邏輯不需要 Mock 就可以測試了，只要校驗方法返回的 Payment 對象里面的屬性是否正確即可。
到這里，你可能又有疑問了，“費了這么大事重構(gòu)代碼僅僅是為了好寫單測，值得嗎?”，如果你有這個疑惑的話，那你可能還是把單測僅僅當成測試了，我之所以要把代碼重構(gòu)的好寫單測，是因為好寫單測的代碼還有其他諸多好處。
易于單測的代碼僅僅是易于單測嗎?
更多的性能優(yōu)化機會
就上面重構(gòu)的代碼為例吧，因為業(yè)務層返回的都是 Payment 對象，我可以這些 Payment 聚合起來，最后統(tǒng)一執(zhí)行，比如下圖的這段代碼，我就可以把 Payment 按照銀行卡分組統(tǒng)一扣錢，這樣就可以減少 rpc 調(diào)用的次數(shù)，以后如果有需要的話，甚至可以直接將 Payment 作為消息發(fā)出去，到另一個系統(tǒng)執(zhí)行，業(yè)務層根本無需關(guān)心 Payment 最后是怎么執(zhí)行，只需要在付款的時候生成一個 Payment 就可以了。
更加健壯的核心代碼
更加健壯的系統(tǒng)
另一個更大的好處是，好寫單測的系統(tǒng)往往比不好寫單測的系統(tǒng)更加健壯，如果一個系統(tǒng)大部分代碼都可以寫無 Mock 單測，那么它看起來就像左圖一樣，外部調(diào)用只是薄薄的一層，可以隨意更換。
如果你的系統(tǒng)大部分代碼都一定要 Mock 才能測試的話，或者根本無法測試的話，就像右圖一樣，說明你的業(yè)務根本就沒有自己的核心邏輯，而是和各種外部調(diào)用纏繞在一起。
另外需要說明的是，圖中紅色的部分才是單測真正能夠起作用的場景，因為它是比較穩(wěn)定的業(yè)務邏輯，而且紅色部分的單測也比較好些，只需要傳幾個參數(shù)進去，然后校驗一下返回值就行了?；疑耐獠空{(diào)用部分理論上不寫單測也無所謂，因為外部調(diào)用是不穩(wěn)定的，即使你跟對方約定好了出入?yún)?shù)，他依舊有可能返回不符合約定的參數(shù)，或者直接就發(fā)生了網(wǎng)絡錯誤，這一部分是集成測試發(fā)揮的場景。為什么在我們的系統(tǒng)里，大家都覺得單測沒用，其實我也覺得單測對我們現(xiàn)在的系統(tǒng)沒什么用，因為我們現(xiàn)在系統(tǒng)的主體代碼就像右圖一樣，大部分都是灰色的外部調(diào)用，單測能夠發(fā)揮作用的領(lǐng)域少之又少，即使寫了覆蓋率 80% 的測試用例，又能測出來啥?
這里要再補充一下，我上面所說的 “穩(wěn)定” 的含義，我說紅色部分的“業(yè)務核心代碼”穩(wěn)定并不是說業(yè)務一成不變，業(yè)務肯定是一直在變的，而是說它的邏輯不會收到外部系統(tǒng)錯誤的影響，不像灰色部分，外部系統(tǒng)一抖動可能就會出問題，因為灰色部分不適合單測。
Mock 工具的定位
剛剛噴了這么久 Mock 工具，那 Mock 工具真正的定位究竟是什么呢?
- Mockito 是用來測試少量的不得不進行外部調(diào)用的代碼。
- PowerMock 是用來測試設計得不好的遺留代碼的。
在 PowerMock 的文檔中已經(jīng)給出了警告，濫用它帶來的壞處或許比好處更多，所以當我們寫單測的時候不應該上來就想著用這些 Mock 工具，而是應該想想如何重構(gòu)代碼才能避開這些工具的使用。
PowerMock 官方文檔的警告：
Putting it(PowerMock) in the hands of junior developers may cause more harm than good.
另外，我們再聊聊單測自動化生成工具，我們剛好也有澄沨在做，無論是哪種單測生成工具，你會發(fā)現(xiàn)工具生成的單測到處都是 Mockito 和 PowerMock，顯然不符合單測的定位，但是這種工具也是有意義的，當系統(tǒng)里到處都是不好寫單測的遺留代碼時，用這個工具生成一下也能幫助我們覆蓋一小部分測試，對于我們系統(tǒng)目前的情況還是很有必要的。
再來一個重構(gòu)的例子
寫有外部調(diào)用的靜態(tài)方法：
最后的結(jié)果：
為了加深大家印象，這里再舉個一個例子。比如下面這個方法，我在靜態(tài)方法中調(diào)用先通過對 Business 的對象的各種處理，拿到了 rpc 調(diào)用的地址和版本號，然后使用這個地址和版本號加載一個初始化好的 hsf(阿里內(nèi)部使用的 rpc 框架)泛化調(diào)用對象返回，這個方法的單測顯然十分難寫，因為 init 會發(fā)生網(wǎng)絡調(diào)用，導致測試失敗。這個時候我們要反思一下單測不好寫的原因，是因為我們違背了一條編碼的基本原則——“不能在靜態(tài)方法中寫外部調(diào)用”，如果你就是想在靜態(tài)方法中進行外部調(diào)用，那應該怎么辦呢?還是像之前的例子一樣，返回一個計劃，讓外部調(diào)用，首先保持代碼無副作用的部分不動，這一部分本來就沒有外部調(diào)用，放在靜態(tài)方法里執(zhí)行也什么事情，然后把外部調(diào)用部分封到一個 Operator 里面(比如這里就是 RpcLoader)返回給上一層，上一層自己選擇立即調(diào)用還是稍后調(diào)用。
這么做除了好寫單測，還有什么好處呢?最顯而易見的一點就是代碼變得可復用了，更重要的一點是防腐，你會發(fā)現(xiàn) hsf 影響范圍被局限在 RpcLoader 里面，以前哪怕它的 API 出現(xiàn)什么變化，或者要換別的框架，都是件非常容易的事情。
為什么單測能夠驗證代碼結(jié)構(gòu)的合理性
前面我提到的這些關(guān)于代碼結(jié)構(gòu)的概念聽起來是不是非常耳熟，在別的領(lǐng)域也經(jīng)常聽到，比如面向?qū)ο笾械?ldquo;高內(nèi)聚，低耦合”，DDD 中所提到的“核心域”，“防腐層”，函數(shù)式編程所倡導的“隔離副作用”，你會發(fā)現(xiàn)，好的編程范式倡導的東西都是類似的。
上面這三種評價代碼的方式其實都是比較“主觀”的，什么樣的代碼才能叫“高內(nèi)聚”，在每個人看來可能都不一樣。但是對于是否易于寫單測，大家的標準基本是一樣的，難寫單測的系統(tǒng)給誰都很難寫。而好寫單測的代碼一般都滿足編程范式所倡導的原則，所以寫單測的難易程度可以作為一個非常客觀的代碼質(zhì)量評價指標。
如果有人跟你說他這段代碼設計得非常好，但是就是不好寫單元測試，千萬不要相信他。
另外再提一下設計模式，如果只是照著書抄抄代碼，設計模式是非常簡單的，關(guān)鍵是要用對場景，一不小心就會只學到了“形”，而沒有學到“神”，“形神兼?zhèn)?rdquo;的設計模式往往會讓代碼變得更加容易測試，如果用了設計模式發(fā)現(xiàn)系統(tǒng)變得更難測試了，那設計模式十有八九用得不對。
如果有個程序員跟你說我程序的性能達到了多少 QPS，你肯定會立馬拿起測試工具就去測，看到底能不能到達這個 QPS。但是如果有程序員畫了框框圖說他的代碼分成了 A B C 模塊，要怎么驗證他的代碼真的分成了這幾個模塊呢?很簡單，你看看每一個模塊能否脫離其他模塊單獨測試就可以了，如果單獨測試非常困難，那就說明模塊并沒有真的分開，而是或多或少耦合在了一起。
易于單測的等級
現(xiàn)在我們可以總結(jié)易于單測的幾等級了。和別的領(lǐng)域不太一樣，別的領(lǐng)域你高級的工具用得越多，可能越厲害，但是在單測這個領(lǐng)域，使用越多的高級工具，反而是更加糟糕的測試。
另外，對這些規(guī)則也不要死腦筋，這些只適合業(yè)務含義比較豐富的代碼，如果你就是在寫一些封裝外部調(diào)用的代碼，這部分代碼我覺得不寫單測也是可行的。
- 第一級，易于單測：大部分代碼不需要 Mock 就可以測試，少量的外部調(diào)用代碼需要 Mockito。
- 第二級，能夠單測：超過一半的代碼需要 Mock 才能測試，但是這些測試也不是特別難寫。
- 第三級，難以單測：大量 Mock，甚至大量使用了 PowerMock。
- 第四級，無法單測：模塊被設計的及其復雜，連開發(fā)者自己都無法理解，更無法寫單測。
二 實踐篇
在上一篇學習了關(guān)于單測的正確觀念后，這一篇再來聊一聊關(guān)于單測的最佳實踐。
單元測試的運行速度重要嗎?
很多人會覺得單測反正也不是系統(tǒng)中的代碼，運行的快慢無所謂，然后寫出很多其慢無比的單測，以至于系統(tǒng)全量跑一次單測要幾十分鐘。這樣的話就完全偏離了單測的定位，單測的目的就是為了方便快速迭代，改了兩行代碼就可以在本地用 30 秒到幾分鐘的時間全量跑一次單測來確定影響范圍，而不是每次都要通讀系統(tǒng)源碼才能知道改動的影響范圍，這樣新人很快就可以大膽改代碼了，而不是先花幾個月通讀系統(tǒng)源碼，或者先踩好幾個坑，才能上手干活。那些全量跑單測要幾十分鐘的系統(tǒng)，他的開發(fā)者根本就不會在本地全量運行單測，每次都在 aone 上跑半天才知道單測不過，這樣的單測就形同虛設了。
違背這個原則的典型反例，就是在單測中啟動 Spring。
數(shù)據(jù)驅(qū)動測試(Data Driven Test)
不好的單元測試常常只用一組正常測試數(shù)據(jù)進行測試，實際上我們應該使用多組數(shù)據(jù)，包括正常和異常數(shù)據(jù)，輸入模塊，看返回值是否符合預期。使用多組測試數(shù)據(jù)是否就意味著多寫很多代碼呢?并不是，我們只要注意將測試用例的邏輯與數(shù)據(jù)分離就可以，測試代碼依次讀取測試數(shù)據(jù)，校驗其是否符合預期。這樣的邏輯與數(shù)據(jù)分離的測試一般稱做 “數(shù)據(jù)驅(qū)動測試”，常見的單元測試框架都會提供這種支持。
"數(shù)據(jù)驅(qū)動測試" 的概念還是太抽象了，這里我們看兩段代碼，左圖未分離數(shù)據(jù)與用例，右圖則做了分離，能夠看出很明顯的不同，右圖是基于 Spock 單元測試框架來寫的，不熟悉的人看上去可能比較奇怪，可以把 where 標簽下的代碼看成一張表格，每一行都是一組測試數(shù)據(jù)，Spock 框架會將其依次代入 testAdd 方法參數(shù)進行測試。
測試數(shù)據(jù)未與用例分離
測試數(shù)據(jù)與用例分離
大家所熟悉的 junit 框架也是可以做的，但是需要寫一個額外的內(nèi)部類，加上@RunWith(Parameterized.class)，寫一個 data 靜態(tài)方法，然后返回需要測試的數(shù)據(jù)組，然后 junit 就會依次將數(shù)據(jù)填入這個類的屬性中，運行這個類中的全部測試用例。
基于 junit 的數(shù)據(jù)驅(qū)動測試
基于 Spock 的數(shù)據(jù)驅(qū)動測試
如何測試私有方法
大家寫單測時常有的一個困惑就是私有方法怎么測試?雖然理論上私有方法不需要寫單測，但是有些私有方法邏輯比較復雜，還是值得單獨寫測試的，目前公認比較好的實踐就是將修飾符從 private 改成 protected, 這也是很多開源項目給單測留口子的方法。如果你的項目剛好有引入 guava 的話，可以再給方法加上一個 @VisibleForTesting 的注解，表示僅僅是出于單元測試需要修改的修飾符。
一個典型的例子：
三 TDD 與 BDD
最后一篇來講一兩個大家可能經(jīng)常聽說過的理念，TDD 和 BDD。個人覺得這兩個理念都比較極端，實際中很難應用，啟發(fā)意義大于其實用意義，所以放在最后，希望能帶來一些啟發(fā)。
TDD
TDD 強調(diào)讓寫代碼的過程形成一個循環(huán)，第一步是為你要做的功能寫一個單元測試，跑一下發(fā)現(xiàn)沒有通過(畢竟你還沒有實現(xiàn)代碼)，即圖中的 TEST FAILS，俗稱“紅燈”，之后編寫能夠通過全部測試的“最小代碼”，之所以強調(diào)“最小代碼”，就是為了防止過度優(yōu)化，現(xiàn)實中我們經(jīng)常會因為代碼過度優(yōu)化，或者過度設計，導致很多遺留問題，在這個階段，只管用最快最臟的代碼實現(xiàn)就好了，不用管太多設計問題。這個階段俗稱“綠燈”。
最重要的就是下面的“重構(gòu)”(REFACTOR)階段了，前面的代碼雖然可能很臟，但是至少是正確，也有足夠的測試來保障邏輯的正確，這個時候就可以大刀闊斧地重構(gòu)代碼了，保證代碼繼續(xù)保持最優(yōu)。
這啟發(fā)我們兩點：
- 單測必須能夠快速運行，因為單測是經(jīng)常要在本地全量運行的，只有運行足夠快，才能在 TDD 的循環(huán)中快速迭代。
- 好的代碼并不是一次性就設計出來的，而是持續(xù)重構(gòu)出來，而單測是持續(xù)重構(gòu)的前提。
BDD
我常常抱怨產(chǎn)品經(jīng)理在提需求時沒有想清楚，比如下圖，如果讓產(chǎn)品經(jīng)理也可以寫出可執(zhí)行的測試用例的話，情況想必會好很多。BDD 就是這么一個想法。
產(chǎn)品經(jīng)理提需求
不知道大家有沒有在有的項目里見過 .story 文件，它本質(zhì)上就是一種集成測試腳本，只不過是用自然語言描述，它包含敘述，場景和步驟三部分，比如上圖就是一個書店管理應用的 .story 文件，文件中敘述(Narrative) 和 場景(Scenario) 只是幫助思考的，本身并包含在測試用例的邏輯中，測試用例主要由 Given, When 和 Then 開頭的語句組成，含義如下：
story 文件示例
story 文件自己當然是無法執(zhí)行的，需要框架提供支持，JBehave 就是這么一種框架(右圖)，能夠定義各種 Given，When，Then 語句的實現(xiàn)，下圖的代碼本質(zhì)上就是個基于 Selenide 的自動化界面點擊測試，它支撐 story 文件的執(zhí)行。我們以這個 story 文件為依據(jù)，就可以像 TDD 循環(huán)一樣，先測試不通過(紅燈)，然后用最小的代碼讓測試通過(綠燈)，最后重構(gòu)代碼。只不過這個循環(huán)可能會耗時好好幾天，乃至幾個星期。而 TDD 一個循環(huán)可能只需要幾個小時，所以說 BDD 是集成測試版的 TDD。
JBehave 框架
敏捷
我們往往會覺得 TDD 和 BDD 會嚴重拖慢迭代速度，值得諷刺的是，TDD 和 BDD 恰恰是敏捷開發(fā)實踐的重要組成部分：
圖源維基百科 Agile software development
我們學習敏捷開發(fā)的時候，常常只學習到它的 “快”，而忽略了敏捷開發(fā)所提出的質(zhì)量保證方法。敏捷開發(fā)所謂的“快”，是指在代碼質(zhì)量充分保證下的“快”，而不是做完功能就直接上線。
四 如何學習寫單測
學習單測的關(guān)鍵還是多實踐，多看看別人好的單測怎么寫。比如可以給一些公認代碼優(yōu)秀的開源項目提交代碼。
五 總結(jié)
- 單測能夠幫助我們驗證代碼設計的合理性。
- 含有核心業(yè)務的代碼應該首先思考如何讓主體業(yè)務邏輯可以寫無 Mock 單測。
- 用例數(shù)據(jù)盡量和測試邏輯分離。
參考資料
參考資料
[1]Test-Driven Java Development
https://www.oreilly.com/library/view/test-driven-java-development/9781783987429/
[2]Wiki Agile software development
https://en.wikipedia.org/wiki/Agile_software_development
[3]PowerMock
https://powermock.github.io/
[4]JBehave
https://jbehave.org/
[5]Spock
http://spockframework.org/
[6]JUnit
https://junit.org/junit4/
[7]Learning to Love TDD
https://medium.com/swlh/learning-to-love-tdd-f8eb60739a69
【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
