首先我就來回答一下标題提出的問題：單元測試除了是一種測試手段外，更是一種改善代碼設計的工具，容易寫單測的代碼往往也具有更加良好的設計。
因而是任何自動化測試工具都無法取代的。
當然，這裡也不是把自動化測試工具給一棍子打死，自動化測試工具也有自己的使用場景，比如測試遺留代碼，做長鍊路測試等等。
這裡需要強調一下 "工具" 屬性，工具能放大人的智力或者體力，讓幹活的時候不會這麼累，比如你去種樹帶把鏟子，你肯定不會把鏟子當成負擔的，因為他是你種樹的工具，你寫 Java，肯定不會因為 IDEA 啟動時間長，就把它當成一種負擔，因為 IDEA 也是你寫 Java 的一個工具，很多人把寫單測當成一種負擔，往往就是沒有意識到"單測"是一種工具，單純把他當成一種測試。
一 品味篇
在品味篇，一起看看什麼樣的代碼才是易于單測的。
Mock 工具的使用——毒藥還是解藥
你可能立刻就會産生和程式員小 A 類似的疑惑："無論代碼寫成什麼樣，通過 Mockito 和 PowerMock 肯定都是能寫出單測來？是以通過單測真的改善代碼結構嗎？"。
實際上，大量使用 Mock 工具的單測相當于買椟還珠，隻具備測試的能力而無法幫助代碼設計。
以一段非常簡單的程式為例，假設這是一個商店系統，裡面有一個買面包的方法，裡面會調用銀行提供的信用卡服務 creditCardService 來扣除傳入的信用卡的錢。這段程式如果使用 Mockito 的話，估計你很快就能寫出測試了，隻需要把 creditCardService 給 Mock 掉，然後驗證它傳入的參數就可以了。
如果總是像上面這樣思考的話，單測對于你改善代碼設計就沒什麼幫助了。我們在給代碼寫單測的時候不應該上來就思考用什麼樣的工具來測試代碼，而是應該思考如何重構代碼，才能讓代碼變得更加容易測試。
還是上面這段代碼，我們換個角度，思考下如何重構代碼，才能讓這段邏輯不需要 mock 就能測試？
其實非常簡單的一個辦法是，傳回一個計劃，而不是立即就執行外部調用，比如這裡我們可以抽象出一個 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 就會依次将資料填入這個類的屬性中，運作這個類中的全部測試用例。
如何測試私有方法
大家寫單測時常有的一個困惑就是私有方法怎麼測試？雖然理論上私有方法不需要寫單測，但是有些私有方法邏輯比較複雜，還是值得單獨寫測試的，目前公認比較好的實踐就是将修飾符從 private 改成 protected, 這也是很多開源項目給單測留口子的方法。如果你的項目剛好有引入 guava 的話，可以再給方法加上一個 @VisibleForTesting 的注解，表示僅僅是出于單元測試需要修改的修飾符。
一個典型的例子：
三 TDD 與 BDD
最後一篇來講一兩個大家可能經常聽說過的理念，TDD 和 BDD。個人覺得這兩個理念都比較極端，實際中很難應用，啟發意義大于其實用意義，是以放在最後，希望能帶來一些啟發。
TDD
TDD 強調讓寫代碼的過程形成一個循環，第一步是為你要做的功能寫一個單元測試，跑一下發現沒有通過（畢竟你還沒有實作代碼），即圖中的 TEST FAILS，俗稱“紅燈”，之後編寫能夠通過全部測試的“最小代碼”，之是以強調“最小代碼”，就是為了防止過度優化，現實中我們經常會因為代碼過度優化，或者過度設計，導緻很多遺留問題，在這個階段，隻管用最快最髒的代碼實作就好了，不用管太多設計問題。這個階段俗稱“綠燈”。
最重要的就是下面的“重構”（REFACTOR）階段了，前面的代碼雖然可能很髒，但是至少是正确，也有足夠的測試來保障邏輯的正确，這個時候就可以大刀闊斧地重構代碼了，保證代碼繼續保持最優。
這啟發我們兩點：
- 單測必須能夠快速運作，因為單測是經常要在本地全量運作的，隻有運作足夠快，才能在 TDD 的循環中快速疊代。
- 好的代碼并不是一次性就設計出來的，而是持續重構出來，而單測是持續重構的前提。
BDD
我常常抱怨産品經理在提需求時沒有想清楚，比如下圖，如果讓産品經理也可以寫出可執行的測試用例的話，情況想必會好很多。BDD 就是這麼一個想法。
不知道大家有沒有在有的項目裡見過 .story 檔案，它本質上就是一種內建測試腳本，隻不過是用自然語言描述，它包含叙述，場景和步驟三部分，比如上圖就是一個書店管理應用的 .story 檔案，檔案中叙述（Narrative） 和 場景（Scenario） 隻是幫助思考的，本身并包含在測試用例的邏輯中，測試用例主要由 Given, When 和 Then 開頭的語句組成，含義如下：
story 檔案自己當然是無法執行的，需要架構提供支援，JBehave 就是這麼一種架構（右圖），能夠定義各種 Given，When，Then 語句的實作，下圖的代碼本質上就是個基于 Selenide 的自動化界面點選測試，它支撐 story 檔案的執行。我們以這個 story 檔案為依據，就可以像 TDD 循環一樣，先測試不通過（紅燈），然後用最小的代碼讓測試通過（綠燈），最後重構代碼。隻不過這個循環可能會耗時好好幾天，乃至幾個星期。而 TDD 一個循環可能隻需要幾個小時，是以說 BDD 是內建測試版的 TDD。
靈活
我們往往會覺得 TDD 和 BDD 會嚴重拖慢疊代速度，值得諷刺的是，TDD 和 BDD 恰恰是靈活開發實踐的重要組成部分：
我們學習靈活開發的時候，常常隻學習到它的 “快”，而忽略了靈活開發所提出的品質保證方法。靈活開發所謂的“快”，是指在代碼品質充分保證下的“快”，而不是做完功能就直接上線。
四 如何學習寫單測
學習單測的關鍵還是多實踐，多看看别人好的單測怎麼寫。比如可以給一些公認代碼優秀的開源項目送出代碼。
五 總結
- 單測能夠幫助我們驗證代碼設計的合理性。
- 含有核心業務的代碼應該首先思考如何讓主體業務邏輯可以寫無 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