要不要搞單元測驗？
一、什么是單元測驗？
單元測驗的基本概念：
對軟體中的最小可測驗單元進行檢查和驗證
①單元的定義：代碼中可度量的最小單元（函式、方法）
②檢查和驗證：不同的輸入對應的輸出是否與預期一致
二、如何進行單元測驗？
1.要進行單元測驗首先需要知道單元測驗需要的幾個基本原則：
①自動化：單元測驗應該是全自動執行的，非互動式的，
②非相互依賴：單元測驗方法的執行順序不應該影響執行結果，各個方法之間不應該相互依賴，
③多設定斷言：盡量多設定斷言，把需要測驗的結果都進行測驗，
④結果唯二：單元測驗只能有兩種結果，通過或失敗，
2.單元測驗的基本流程：
①Arrange 準備階段：設定前提條件，比如初始化物件、模擬資料等等，
②Act 行為階段（執行動作）：呼叫被測驗的方法，并得到回傳結果，
③Assert 斷言階段（驗證結果）：把呼叫目標方法回傳的值和預期的值進行比較，如果和預期一致說明測驗通過，否則就是失效，
3.單元測驗示例
以C#平臺的MSUnit測驗框架演示
①簡單模擬一個用戶類及種子資料
②準備寫好待測驗的生產代碼（以客戶端開發常用的單例舉例）
③撰寫單元測驗
4.例外捕獲測驗
一些底層專案需要拋出例外，這種情況下我們需要對相應的例外也做出測驗，
三、Mock框架-Moq
Mock在單元測驗中是一個很重要的概念，
? Mock是模擬的意思，Mock框架就是用來模擬物件的一個技術，一般在一下幾種情況下用：
①真實物件具有不確定行為（比如不可預測的結果，類似股票）
②物件很難被創建
③物件的某些行為很難觸發（例如網路錯誤）
④測驗需要驗證某個回呼函式是否被呼叫
⑤物件并不存在（多端的情況下或者和其他專案或服務打交道的時候）
以Moq框架為例，假設我們現在需要通過一個公司物件獲取到該公司旗下的所有游戲，該方法依賴一個公司物件，
但是，這個公司物件以介面形式用公司名稱獲取，我們并不知道介面實作和公司資料庫，
這時，我們就可以用Moq模擬一個公司倉儲的實體，并設定好一些輸入對應的輸出結果，
“2”中的意思也就是說，當針對這個方法輸入“南山必勝客”的時候，方法會回傳Returns里面的物件，（例子不好，但是這么個意思）
“南山必勝客”懂得都懂
最后可以運行測驗，得到測驗結果，當我們看到一片綠的時候，心情是不是舒暢很多呢：）
四、為什么需要單元測驗？
1.單元測驗能解決的問題
①提高代碼質量：
? 對于每個最小的單元，針對不同輸入對應的輸出可以和預期結果做對比，減少因為引數導致的例外問題，代碼變得更加健康，增加新需求時不用擔心影響原來代碼邏輯，
②代碼耦合度低、模塊化：
? 若要對一個模塊單元進行單元測驗，需要將每個單元拆分得相對獨立，使得代碼的邏輯、結構清晰，減少單元之間的依賴，代碼出現bug更容易定位，
③代碼可重用：
? 經過單元測驗的代碼，既穩定又獨立，可以更加方便的在其他專案或者專案重構時重復利用，
④代碼可讀性強：
? 單元測驗某種程度上相當于系統的檔案，借助于查看單元測驗提供的功能和單元測驗中如何使用單元，開發人員可以直觀的理解每個單元的功能，
2.單元測驗的缺點
①浪費開發時間（寫單元測驗需要大量的時間，不如直接寫具體的實作），有些模塊根本無法進行單元測驗（無回傳值的方法、UI界面）
②不能發現集成錯誤、性能問題、或者其他系統級別的問題，單元測驗結合其他軟體測驗活動更為有效，
單元測驗還是應該多搞，不為別的，就為了看到那一片綠色，嘿嘿...
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/244590.html
標籤：其他
下一篇：如何降低API檔案對接成本