【MVC拾遺】MVC的單元測試簡單學習總結

關於測試的必要性什麼的已經在 重構與測試 裏扯過了。倒也不必說，寫的代碼多了天然就明白這個東西重要性。

當時說了坐等被推進去學習單元測試來着，然而等着被人推進的結果就是根本就沒人來推你。o(∩_∩)o

因此仍是本身主動來學，主動來總結了。

可測試性設計基礎理論知識

可測試性設計（Design for Testability, DFT）是一種集成電路技術，它將一些特殊結構在設計階段植入電路，以便設計完成後進行測試。

後來這種玩法被應用到了軟件之中。它關注的是在正確的、錯誤的、丟失的和不完整的輸入下的輸出是否符合預期。

具備可測試性的軟件通常是採起鬆散設計，目的是爲了方便測試軟件去調用，那麼低耦合就是它的原則了。（話說回來，就算不爲了可測試性，低耦合也很重要啊）

好比基於接口來編程，就是衆所周知的降耦合的方法之一，減小測試時的依賴性。

編寫可測試性代碼的時候，也是對代碼結構的一個評審，由於一個在測試中沒法輕鬆實例化的類，那麼就一定會存在耦合問題。

測試的代碼也應該保證效率，而低耦合也能夠減小一些無用的測試環境的配置，那麼測試代碼的運行速度就會提高，這在大的項目中尤其重要。

若是不能使代碼的結構低耦合，那麼就不是單元測試了，而變爲了集成測試。

雖然集成測試一樣有必要，可是不管是運行速度上仍是對於問題發生後定位問題的速度上而言，都不如單元測試方便。

關於單元測試

單元測試（unit testing），是指對軟件中的最小可測試單元進行檢查和驗證。

上面是單元測試的百度百科定義。

單元測試包括編寫和運行一個小的程序，以自動的方法實例化測試類以及調用測試方法。

若是咱們要手動去寫代碼去測試一個程序，雖然是可行的，可是畢竟耗時耗力，因此執行單元測試的最有效和最多見的方式是使用自動化的測試框架。

這個框架一般包括一個運行時引擎和一個類的框架，用於簡化測試程序的建立。

經常使用的自動化測試框架有：MSTest、NUnit以及xUnit.net。

MSTest看這名字就直到來自微軟，也就自動集成在VS中了，而爲了懶得下別的資源的緣由o(︶︿︶)o ，這裏就用MSTest了。

單元測試中有測試固件這麼個概念，實際上就是一個用於測試的類，這個類建立和結束的時候可能還會去設置測試環境和消除測試環境什麼的。（因此咱們後面仍是就叫測試類吧）

測試方法的典型設計能夠總結爲：設置、做用和斷言。（簡單來說，第一步設置測試環境，第二步將測試代碼做用於須要測試的代碼上，第三步將輸出結果與預期的斷言進行驗證）

單元測試是由數據驅動的測試，用不一樣的數據（好比臨界值，錯誤值什麼的）去測試代碼的可靠性。

雖然單元測試也是寫代碼，可是與日常的寫代碼仍是有些區別的：

• 測試範圍儘量小。就像單一職責原則同樣，目的明確。這樣作不只有助於快速定位問題，有助於測試代碼的可讀性。
• 隔離測試。即在測試一個方法時，擺脫該方法全部的依賴性，而專一於測試該方法自己。
• 僞造和模擬。實際上這個東西就是爲了配合隔離測試來的，當一個類確確實實只能依賴於另外一個類時，那麼就用僞造和模擬一個對象去替代被依賴的類的對象。
  • 僞造對象就是對一個對象的簡單克隆，提供與原始對象相同的接口，可是返回硬編碼的值。
  • 模擬對象比僞造對象更復雜，它涉及到要去模擬原始對象的一些交互
• 一個斷言。這個是一個爭議點，就是爲了保證測試範圍儘量小。然而在實際操做中，可能會存在不少類似的測試，因此也能夠去在一個測試中運用多個斷言。
• 測試非公共成員。方法就是給所測試的類添加一個新類，而後這個新類有一些受保護的方法去調用那些要測試的非公共成員。
• 代碼覆蓋率。用來計算被測試的系統中的代碼有多少被測試代碼測到了，以此來評估測試的可靠性。然而盲目地去提升代碼覆蓋率並不能說明測試的相關性和有效性，測試的關聯性纔是重要的。

MVC的單元測試實戰

來吧，到了上點乾貨的時候了，實戰永遠比枯燥的理論有趣多了。

MVC的實現了控制器、視圖、模型的分離，而且不像WebForm那樣對Request和Session這些內部組件過於依賴，使得它成爲了一個便於單元測試的框架。

首先建立單元測試項目。

被測試的代碼就是VS2015下，不帶賬號系統的MVC項目。如下爲VS自動建立的單元測試項目。

能夠看到默認的有一個Controller文件夾，下面爲控制檯測試文件。能夠聯想到，也能夠加一個service或business文件夾去測試代碼的業務邏輯。（一般而言更多的測試其實都是針對業務層，由於控制器的代碼邏輯通常都比較簡單）

那麼看看默認的測試類HomeControllerTest中具體的代碼：

用TestClass特性去標註測試類，TestMethod特性去標註測試方法。

而觀察Index中的代碼：

首先聲明要測試的控制器類，也就是準備好測試環境，

而後用控制器實例去調用要測試的函數，

最後用斷言去判斷返回的結果是否符合預期。

 讓咱們再加三個特性的用法

而後啓動測試什麼的也很簡單：

測試的結果會顯示在測試資源管理器中：

很明顯看到被Ignore特性標註的被跳過了測試。還能夠選擇測試資源管理器中的測試而後進行單個測試，而不是像以前那樣測試全部。

其實說穿了單元測試這個東西玩法很簡單，須要去掌握的反而是以前的那些理論知識，保證測試的質量和高效。

提及來單元測試麻煩的地方可能也就是去解除依賴性了吧，主要是模擬交互，這個扯起來就麻煩了，百度了一下還有模擬交互的各類框架什麼的，並且一些模擬Http上下文的要用到。

不過我想總會有簡單的解決辦法的，本質上模仿也只是僞造的交互版本而已，那麼將僞造的返回結果豐富多樣化，那麼不就是模仿了嗎？

一點拙見啦~

OK，雖然單元測試是個能夠簡單入門的東西，可是難度仍是有的。

除了上面寫到的解除依賴性，最重要的仍是實施和堅持。

從明天開始慢慢來把它歸入項目中吧!