要不要單元測試？

要不要搞單元測試？

1、什麼是單元測試？

單元測試的基本概念：

對軟件中的最小可測試單元進行檢查和驗證

①單元的定義：代碼中可度量的最小單元（函數、方法）

②檢查和驗證：不一樣的輸入對應的輸出是否與預期一致

2、如何進行單元測試？

1.要進行單元測試首先須要知道單元測試須要的幾個基本原則：

①自動化：單元測試應該是全自動執行的，非交互式的。

②非相互依賴：單元測試方法的執行順序不該該影響執行結果，各個方法之間不該該相互依賴。

③多設置斷言：儘可能多設置斷言，把須要測試的結果都進行測試。

④結果惟二：單元測試只能有兩種結果，經過或失敗。

2.單元測試的基本流程：

①Arrange 準備階段：設置前提條件，好比初始化對象、模擬數據等等。

②Act 行爲階段（執行動做）：調用被測試的方法，並獲得返回結果。

③Assert 斷言階段（驗證結果）：把調用目標方法返回的值和預期的值進行比較，若是和預期一致說明測試經過，不然就是失效。

3.單元測試示例

以C#平臺的MSUnit測試框架演示

①簡單模擬一個用戶類及種子數據

②準備寫好待測試的生產代碼（以客戶端開發經常使用的單例舉例）

③編寫單元測試

4.異常捕獲測試

一些底層項目須要拋出異常，這種狀況下咱們須要對相應的異常也作出測試。

3、Mock框架-Moq

Mock在單元測試中是一個很重要的概念，

​ Mock是模擬的意思，Mock框架就是用來模擬對象的一個技術。通常在一下幾種狀況下用：

①真實對象具備不肯定行爲（好比不可預測的結果，相似股票）
②對象很難被建立
③對象的某些行爲很難觸發（例如網絡錯誤）
④測試須要驗證某個回調函數是否被調用
⑤對象並不存在（多端的狀況下或者和其餘項目或服務打交道的時候）

以Moq框架爲例，假設咱們如今須要經過一個公司對象獲取到該公司旗下的全部遊戲，該方法依賴一個公司對象。

可是，這個公司對象以接口形式用公司名稱獲取，咱們並不知道接口實現和公司數據庫。

這時，咱們就能夠用Moq模擬一個公司倉儲的實例，並設置好一些輸入對應的輸出結果。

「2」中的意思也就是說，當針對這個方法輸入「南山必勝客」的時候，方法會返回Returns裏面的對象。（例子很差，可是這麼個意思）

「南山必勝客」懂得都懂

最後能夠運行測試，獲得測試結果。當咱們看到一片綠的時候，心情是否是舒暢不少呢：）

4、爲何須要單元測試？

1.單元測試能解決的問題

①提升代碼質量：

​ 對於每一個最小的單元，針對不一樣輸入對應的輸出能夠和預期結果作對比，減小由於參數致使的異常問題，代碼變得更加健康，增長新需求時不用擔憂影響原來代碼邏輯。

②代碼耦合度低、模塊化：

​ 若要對一個模塊單元進行單元測試，須要將每一個單元拆分得相對獨立，使得代碼的邏輯、結構清晰，減小單元之間的依賴。代碼出現bug更容易定位。

③代碼可重用：

​ 通過單元測試的代碼，既穩定又獨立，能夠更加方便的在其餘項目或者項目重構時重複利用。

④代碼可讀性強：

​ 單元測試某種程度上至關於系統的文檔。藉助於查看單元測試提供的功能和單元測試中如何使用單元，開發人員能夠直觀的理解每一個單元的功能。

2.單元測試的缺點

①浪費開發時間（寫單元測試須要大量的時間，不如直接寫具體的實現），有些模塊根本沒法進行單元測試（無返回值的方法、UI界面）

②不能發現集成錯誤、性能問題、或者其餘系統級別的問題。單元測試結合其餘軟件測試活動更爲有效。

單元測試仍是應該多搞，不爲別的，就爲了看到那一片綠色，嘿嘿...