關於測試的必要性什麼的已經在 重構與測試 里扯過了。倒也沒必要說，寫的代碼多了自然就明白這個東西重要性。 當時說了坐等被推動去學習單元測試來著，然而等著被人推動的結果就是根本就沒人來推你。o(∩_∩)o 所以還是自己主動來學，主動來總結了。 可測試性設計基礎理論知識 可測試性設計（Design fo ...
關於測試的必要性什麼的已經在 重構與測試 里扯過了。倒也沒必要說，寫的代碼多了自然就明白這個東西重要性。
當時說了坐等被推動去學習單元測試來著，然而等著被人推動的結果就是根本就沒人來推你。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，雖然單元測試是個可以簡單入門的東西，但是難度還是有的。
除了上面寫到的解除依賴性，最重要的還是實施和堅持。
從明天開始慢慢來把它納入項目中吧!
