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