為什麼很多技術或者知識要說優點？因為有些道理看著很簡單，大家表面上都覺得對，但是做的時候又不去做或者做不到。其中有乙個很重要原因是骨子裡或者潛意識並沒有真實覺得這是對的，一旦想去做的時候同時會冒出更多不去做的理由。
很多小夥伴在編寫方法或者程式的時候，先簡單寫一下「大體」的邏輯。好一些的，在寫完後，會根據不同"情況"驗證一下，如果有錯再繼續修改。但是往往更多的情況下，自己也不知道這個方法對外是一種什麼形態，需要滿足多少種情況，在異常的情況下提供的是什麼表現。所以最終需要使用者（有可能是服務呼叫者，測試者或者真正的使用者）來糾正問題，然後再去修訂。明確服務職責邊界這樣一來，整個編寫方法的週期其實更長，資源的損耗更大。
最好是單一的職責（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是非常好造的。
當前，在編寫單元測試的時候也會有很多任務作量，所以可以通過單元測試框架來解決重複的問題。
單元測試不是越多越好，而是越有效越好！進一步解讀就是哪些**需要有單元測試覆蓋：(引用kent beck)
寫單元測試的時機不外乎三種情況：
我個人推薦的是，先大體明確方法的職責和邊界，然後把突出的case大體設計出來。然後和具體實現**同步。一來可以補充case，只有對需求有一定的理解後才能知道什麼是**的正確性，才能寫出有效的單元測試來驗證正確性，而能寫出一些功能**則說明對需求有一定理解了。二來可以使用重構的思維去解決思考兩次而且還互相打架的問題。多驗證點的case，一旦業務稍微改變一點點，很容易造能case的通過不了，也說明了方法的職責不是很原子。有可能可以進一步拆分。
說明方法不夠健壯，職責不清楚。如果一旦上下文變更，就會導致case的失敗。介時就分不清楚是上下文資料的問題，還是自己服務的問題。
雖然，單元測試框架做了很多重複的事，但是還有很多重複的事，其實都是可以封裝成工具類的。
比如：乙個方法有很多引數，然後每個引數都都可以賦預設值，那就得手寫半天。像這種抽象上一致的都可以封裝成工具類
在不同的單元測試之間，其實有很多重複的思考和溝通。
比如：單元測試的方法名怎麼命名更好些？乙個方法放乙個case還是多個case。什麼樣的異常需要驗證case。
有了規範或者規約後。重複的內容可以通過**片段，檔案模板等方式半自動化的生成，甚至可以通過**生成器等小工具，預設把一些手工的操作怎麼自動生成。而且規範後，大家閱讀和維護單元測試的成本就會降低。
理想狀態的單元測試，應該是只驗證正確的業務點，和異常的業務點，以及一些從系統和抽象問題領域角度的異常業務點。其他的要麼交給工具，要麼交給規範。
真的要做單元測試嗎？
單元測試可以降低 的耦合度。我們知道，耦合度高的 很難做單元測試，反過來，如果你必須做單元測試，你是不會把 寫的耦合度很高的 打個比方，單元測試像是花盆裡的沙子，它會降低土壤的粘度。單元測試可以讓你知道你對 的修改是否影響到了原來就有的功能。但是這也是所有的回歸測試都可以做的。單元測試的特點在於 它...
為什麼需要單元測試
軟體開發的標準過程包括以下幾個階段 需求分析階段 設計階段 實現階段 測試階段 發布 其中測試階段通過人工或者自動手段來執行或測試某個系統的過程，其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。測試過程按4個步驟進行，即單元測試 整合測試 系統測試及發版測試。其中功能測試主要檢...
為什麼需要單元測試
軟體開發的標準過程包括以下幾個階段 需求分析階段 設計階段 實現階段 測試階段 發布 其中測試階段通過人工或者自動手段來執行或測試某個系統的過程，其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。測試過程按4個步驟進行，即單元測試 整合測試 系統測試及發版測試。其中功能測試主要檢...