單元測試er——爲何真的真的要寫單元測試

優勢

爲何不少技術或者知識要說優勢？由於有些道理看着很簡單，你們表面上都以爲對，可是作的時候又不去作或者作不到。其中有一個很重要緣由是骨子裏或者潛意識並無真實以爲這是對的，一旦想去作的時候同時會冒出更多不去作的理由。

方法更健壯

更明確方法的職責

不少小夥伴在編寫方法或者程序的時候，先簡單寫一下「大致」的邏輯。好一些的，在寫完後，會根據不一樣"狀況"驗證一下，若是有錯再繼續修改。可是每每更多的狀況下，本身也不知道這個方法對外是一種什麼形態，須要知足多少種狀況，在異常的狀況下提供的是什麼表現。因此最終須要使用者（有多是服務調用者，測試者或者真正的用戶）來糾正問題，而後再去修訂。
這樣一來，整個編寫方法的週期其實更長，資源的損耗更大。

明確服務職責邊界

最好是單一的職責（web層或者流程聚合的接口除外）。

如今是作一個判空的工具。首先要分析的是這個判空的服務範圍和職責。一個集合判空、一個字符串判空，跟一個同時支持，包裝類，字符串（包括Char等），集合，數組，字典，對象等的判空。這就是兩個徹底不一樣的職責。不一樣的職責最終的case是不一樣的。

明確正常case

通常是根據第一步的服務範圍和職責來提供的，這樣是黑盒，和使用者的視角是同樣的（推薦）。也有喜歡經過白盒列case的，經過if等拐點來肯定case（不是很推薦）。最終要保證對的確定是對的，並且要和預期結果同樣。

明確異常的case

特別重要的是需求明確的異常，好比說，須要去支付，可是你的錢是非法的。還有抽象域的一些問題要考慮：好比說：冥等，批量操做時的原子性，依賴服務異常等。最終要保證錯的必定要錯

明確case輸入

明確每個case輸入應該是什麼，只關注和這個case相關的，這樣每一個都是具義的。若是一個case有太多的輸入和case無關，最好是考慮對依賴的結點進行mock。

明確case輸出

明確每個case輸出是什麼。這樣能夠進行斷點和結果預期。而後執行時，就能反向知道這個方法提供的服務是否正確。若是不正確的話，須要修改方法。

大膽重構

只有有case了，才能使用自動化的驗證。不然有可能只是改了一個很小的地方，可是會引發其餘case的錯誤，改一個小地點就得手動的把全部case測試一下。並且最懼怕的是歷史方法，由於沒有人能說清楚到底有多少種case。

重構時錯誤常見的場景：

• 一個判斷條件或者設計的鏈路，想的是對的，可是寫的時候出錯，致使正常業務都出錯了
• 誤刪或者重構時遺漏代碼，致使部分業務錯誤。

讓編寫的方法更獨立

一旦耦合度過高，在造輸入數據的時候就會特別困難。這樣也反向的能促進咱們在寫代碼的時候儘量的不依賴，至少不深度或者嵌套依賴。

好比：之前是寫個a方法，要知道b方法使用c對象的d屬性。這樣造輸入的時候就特別難受。因此就會促進咱們變成寫個a方法，最多使用和關心b方法。其餘是b方法的職責，讓b方法本身去測試。

這樣也能讓每一個方法更原子和內聚。

隔離依賴

無感依賴細則

不用關注依賴的細則，特別是不用跨層或者跨服務去關注細節。從樹狀結構關注點變爲平級關注點。從關注細則到關注服務。

並行開發

之前的方式是，相互耦合依賴，上游沒作完，下游沒數據，沒辦法或者很難並行開發。可是使用隔離後，就能夠基於接口的服務職責來mock預期的行爲，因此互相就不會依賴，能夠並行去開發。

結果可預見

比較頭疼的是，要根據不一樣的業務case,造各類場景，有的場景還要開關或者編數據等特殊方式才能夠。可是使用隔離mock後，想要有什麼預期結果是很是穩定的，也是很簡單天然的。
好比：有N個集合中，調用指定的服務後，若是有部分失敗，部分紅功。這個case用mock是很是好造的。

解決重複問題

當前，在編寫單元測試的時候也會有不少工做量，因此能夠經過單元測試框架來解決重複的問題。

• mock簡潔化和自動化。經過註解和ioc基本很容易作到。
• 設置參數很頭疼，還有不少魔鬼數字，有的時候還得硬着頭皮造一些無喱頭的數據。

寫什麼

單元測試不是越多越好，而是越有效越好！進一步解讀就是哪些代碼須要有單元測試覆蓋：(引用Kent Beck)

• 邏輯複雜的
• 容易出錯的
• 不易理解的，即便是本身過段時間也會遺忘的，看不懂本身的代碼，單元測試代碼有助於理解代碼的功能和需求
• 公共代碼。好比自定義的全部http請求都會通過的攔截器；工具類等。
• 核心業務代碼。一個產品裏最核心最有業務價值的代碼應該要有較高的單元測試覆蓋率。

怎麼寫

• 根據case準備數據,mock
• 觸發驗證場景
• 期待的結果是什麼

什麼時候寫

寫單元測試的時機不外乎三種狀況：

• 在具體實現代碼以前，這是測試驅動開發（TDD）所提倡的；
• 與具體實現代碼同步進行。先寫少許功能代碼，緊接着寫單元測試（重複這兩個過程，直到完成功能代碼開發）。其實這種方案跟第一種已經很接近，基本上功能代碼開發完，單元測試也差很少完成了。
• 編寫完功能代碼再寫單元測試。個人實踐經驗告訴我，過後編寫的單元測試「粒度」都比較粗。對一樣的功能代碼，採起前兩種方案的結果多是用10個「小」的單測來覆蓋，每一個單測比較簡單易懂，可讀性可維護性都比較好（重構時單測的改動不大）；而第三種方案寫的單測，每每是用1個「大」的單測來覆蓋，這個單測邏輯就比較複雜，由於它要測的東西不少，可讀性可維護性就比較差

我我的推薦的是，先大致明確方法的職責和邊界，而後把突出的case大致設計出來。而後和具體實現代碼同步。一來能夠補充case，只有對需求有必定的理解後才能知道什麼是代碼的正確性，才能寫出有效的單元測試來驗證正確性，而能寫出一些功能代碼則說明對需求有必定理解了。二來可使用重構的思惟去解決思考兩次並且還互相打架的問題。

陷阱

多驗證點

多驗證點的case，一旦業務稍微改變一點點，很容易造能case的經過不了，也說明了方法的職責不是很原子。有可能能夠進一步拆分。

過分依賴上下文

說明方法不夠健壯，職責不清楚。若是一旦上下文變動，就會致使case的失敗。介時就分不清楚是上下文數據的問題，仍是本身服務的問題。

還須要作的事

工具類庫

雖然，單元測試框架作了不少重複的事，可是還有不少重複的事，其實都是能夠封裝成工具類的。
好比：一個方法有不少參數，而後每一個參數都均可以賦默認值，那就得手寫半天。像這種抽象上一致的均可以封裝成工具類

規範

在不一樣的單元測試之間，其實有不少重複的思考和溝通。
好比：單元測試的方法名怎麼命名更好些？一個方法放一個case仍是多個case。什麼樣的異常須要驗證case。

有了規範或者規約後。重複的內容能夠經過代碼片斷，文件模板等方式半自動化的生成，甚至能夠經過代碼生成器等小工具，默認把一些手工的操做怎麼自動生成。並且規範後，你們閱讀和維護單元測試的成本就會下降。

理想狀態的單元測試，應該是隻驗證正確的業務點，和異常的業務點，以及一些從系統和抽象問題領域角度的異常業務點。其餘的要麼交給工具，要麼交給規範。

參考資料

• 爲何要寫單元測試，什麼時候寫，寫多細
• mockito官方文檔