迭代5 建立單元測試
本次迭代
在上一次對Contact Manager的迭代中，我們通過使用一些設計模式對 程序進行了重構，松散了類之間的耦合。我們將controller、service和repository層分別 獨立出來。每層都基於接口與其他層進行交互。
通過重構，應用程序變得更以維護 和修改。假如某天你需要使用其他的數據存儲技術，那麼只要簡單的替換repository層即可 ，並不需要去碰controller或service層中的代碼。
但當我們需要向Contact Manager中添加新功能或修正bug時呢？殘酷的事實告訴我們，每當我們改動代碼的時候，也 必定要承擔新bug出現的風險。
例如某天，你的頭需要你向Contact Manager中添加 一項新功能。她要求程序支持對聯系人信息進行分組，她要求用戶可以自定義一些如 “朋友”，“同事”租入此類的分組從而組織他們的聯系人信息。
為了實現這項功能，你需要修改Contact Manager中全部三層之中的代碼。你需要向 controller、service、repository層中添加一系列的新函數。從你開始修改代碼的那一刻 開始，你就必須承擔有可能破壞原本正常工作的那部分功能的風險。
上次我們將應 用程序重構並將其分散到若干獨立的層中，這使得我們可以在不觸碰其他代碼的情況下對某 層做出改變。然而，當你希望這個具體的層中的代碼更易維護和修改時，你應當為代碼建立 單元測試。
你可以通過單元測試針對特定的代碼單元進行測試。這些代碼單元要比 整個層小得多。例如你測試代碼中的某個特定的方法，確認其是否達到預期的功能及表現， 這就是一個經典的單元測試場景。如你想要對ContactManagerService類公開的 CreateContact()方法進行單元測試。
單元測試對於整個應用程序的開發過程而言更 像一個安全網絡。當你想修改應用程序中的代碼時，你可以進行一系列的單元測試來檢測是 否你的新代碼對原有功能產生了破壞。單元測試為你的代碼修改工作提供了更高的安全系數 ，同時單元測試也使得應用程序中的代碼變更場景更具彈性。
在這次迭代中，我們 向Contact Manager添加單元測試。得益於此，在下一次迭代中我們可以為其添加新的聯系 人分組功能，同時又無需顧慮這些改變是否會對原有功能產生影響。
那麼就從這裡 開始
在完美的世界中，應用程序中的所有代碼都是經過單元測試的。在完美的世界 中，你擁有一個完美的安全網絡體系，你可以修改應用程序總的任意一行代碼並且立即通過 單元測試得知這些改動是否會對原有的功能產生影響。
然而這個世界在大部分的情 況下還不夠完美。在實踐中,當我們進行單元測試時,你需要集中精力針對業務邏輯進行測驗 (例如,驗證邏輯)。在特殊情況下,你無需對數據訪問邏輯或視圖邏輯進行單元測試。
單元測試必須是可以快速執行的。你將很輕易的為應用程序積累成百上千的單元測 試。如過運行某些單元測試十分耗時，則你應當避免執行它們。換句話說，耗時的單元測試 對日常的編碼工作並無益處。
因此，你無需對與數據庫實際交互的代碼進行單元測 試。運行幾百個針對數據庫的單元測試將十分緩慢。你應當對你的數據庫進行mock，然後編 寫代碼與mock的數據庫進行交互。（下面我們將討論如何對數據庫進行mock）
相似 的，你無需針對view進行單元測試。要想對view進行測試，你就不得不搭建web服務器。因 為搭建web服務器相對來說也很耗時，這裡並不推薦針對view進行單元測試。
如果你 的view包含大量復雜的邏輯，則你應當考慮將這些邏輯轉移到Helper方法中。你可以針對 Helper方法編寫單元測試且無需搭建web服務器。
雖然針對數據存儲邏輯或試圖的測 試並不被推薦，但這些測試可能在集成測試或功能測試時十分有用。
ASP.NET MVC默 認使用Web Form試圖引擎。該引擎依賴於web服務器，其他的試圖引擎或許不盡如此。
