關於視圖的單元測試
說到ASP.NET MVC，我們似乎始終都在關注對於Controller的測試——雖然Stephen Walther也寫過如 何脫離Web Server對View進行單元測試，但是他的方法可看而不可用。復雜的構造和預備，以及對生成的 HTML字符串作判斷——這真是在對視圖做單元測試嗎？仔細分析他的代碼可以發現，這其實是在對 ViewEngine做單元測試。而且，如果真要對ViewEngine做單元測試，也不應該像他那樣依賴外部文件。在 我看來，他的做法什麼都不是……似乎美觀，似乎能博得一些“掌聲”，但是這個掌聲是來自於他的解決 方案，還是大家一時的沖動呢？
如果要對視圖做單元測試，還是要將內容呈現在浏覽器中才行。在對網頁做單元測試時，我們一般會 使用WatiN等工具操作浏覽器，打開頁面，再對其DOM元素結構及內容作斷言。不過……這是單元測試嗎？ 可惜這只能算是一種回歸測試或用戶驗收測試。因為，我們在打開一個頁面的時候，從表現層到業務邏輯 再到數據訪問，應用程序的每個部件都在忙碌著。而單元測試講究的是“分離”，分離一切關注，分離一 切依賴。因為分離，我們才能准確定位錯誤；因為分離，我們才能在測試中使用我們准備好的數據。
既然要分離，我們就必須遵循一定的使用規范。在《ASP.NET MVC單元測試最佳實踐》中我提到，在 View中只能使用ViewData中的數據，而不該依賴其他內容（包括HttpContext）。這樣我們就可以自行構 造ViewData並注入一個視圖對象中。事實上，這個約定在ASP.NET MVC自帶的項目模板中就被破壞了。請 看Views\Shared\LogOnUserControl.ascx，其中通過this.User來查看當前用戶的登陸狀態。這是個定義 在傳統Page對象上的屬性，從當前HttpContext上直接獲取。如果使用這種方式，我們在單元測試時就難 以“模擬”當前用戶的登陸狀態，進而難以使測試覆蓋到測試的各種情況了。
Lightweight Test Automation Framework
在這裡，老趙推薦使用ASP.NET Team提供的Lightweight Test Automation Framework（下文稱之為 LTAF）作為測試工具，它目前已經在CodePlex上更新至Feb Update版本。這個框架的作用與WaitN和 Selenium類似，可操作浏覽器對應用程序編寫回歸測試。雖然在某些方面（例如DOM元素的選取）不如“ 競爭對手”，但是LTAF自有其獨到之處：
由於直接在浏覽器中運行，它天生便支持現有的——以及未來可能出現的任意浏覽器。
由於直接部署在被測試的網站中，因此測試代碼和網站頁面是在同一個進程中。
第一點優勢自不必說，而第二點更是關鍵。試想WaitN和Selenium，都是通過編寫代碼在浏覽器中打開 頁面。這意味著我們的在測試代碼和被測試的網頁分別在不同的進程中。在這個前提下，如果我們要將測 試代碼中定義的數據傳遞給被測試的網頁（也就是視圖對象），我們就必須進行跨進程的通信。而無論怎 麼實現，都逃不過“序列化”一途，這無疑增加了復雜度。而使用LTAF之後，這個問題瞬間煙消雲散了， 因為我們可以直接在內存中“傳遞”測試數據，一切都只是個引用而已。
不過任何事物都具有兩面性，LTAF也有一些難以天生的，而且是永遠無法彌補的缺點。例如：
由於LTAF將待測試的頁面放置在Frame中，因此該頁面上的window.top等基於浏覽器frame結構的屬性 會被改變。
由於LTAF的本質是使用JavaScript來操作DOM，這意味著任何會阻塞程序進行的操作（例如alert）都 不能使用，否則將阻塞整個測試過程。
不過幸運的是，這兩點都不回成為嚴重的問題。對於第一種，我們只需要編寫一個自定的getTop方法 來替換直接訪問windows.top的做法即可。而第二種情況——老趙從來不喜歡alert或confirm這種“純浏 覽器功能”，因為它們會帶來很差的用戶體驗，更何況現在的JavaScript類庫/框架都能很輕松的做出這 種效果，您覺得呢？
LTAF的具體使用方式可參考其Release Note。令人奇怪的是，老趙發現直接在項目中使用LTAF會有一 些小問題（不過它的示例為什麼就一切正常呢？），因此進行了一些細微的修改。請注意 ~\UnitView\DriverPage.aspx文件尾部的一些JavaScript代碼。
