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