對ASP.NET MVC項目中的視圖做單元測試

關於視圖的單元測試

說到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版本。這個架構的作用與WatiN和Selenium類似，可操作瀏覽器對應用程式編寫迴歸測試。雖然在某些方面（例如DOM元素的選取）不如“競爭者”，但是LTAF自有其獨到之處：

由於直接在瀏覽器中運行，它天生便支援現有的——以及未來可能出現的任意瀏覽器。
由於直接部署在被測試的網站中，因此測試代碼和網站頁面是在同一個進程中。

第一點優勢自不必說，而第二點更是關鍵。試想WatiN和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代碼。

UnitView的使用

於是老趙編寫了一個組件UnitView，方便我們構造一個單元測試時所需的資料。有了資料，便能夠直接將視圖在瀏覽器中加以呈現了。例如：

[WebTestClass]

public class HomeTests

{

[WebTestMethod]

public void LoggedOnIndexTest()

{

var data = new TestViewData

{

ControllerName = "Home",

ActionName = "Index",

Model = new IndexModel

{

Message = "Welcome guys!",

Identity = new UserIdentity

{

IsAuthenticated = true,

Name = "Jeffrey Zhao"

}

}

};

HtmlPage page = new HtmlPage(TestViewData.GenerateHostUrl(data));

// Assert title

Assert.AreEqual("Home Page", page.Elements.Find("title", 0).GetInnerText());

// Assert head element

var mainContent = page.Elements.Find("main");

var head2 = mainContent.ChildElements.FindAll("h2").Single();

Assert.AreEqual(data.Model.Message, head2.GetInnerText(), "Message should be displayed.");

var loginTabInnerText = page.Elements.Find("logindisplay").GetInnerTextRecursively();

Assert.IsTrue(loginTabInnerText.Contains("Welcome"), "'Welcome' missed.");

Assert.IsTrue(loginTabInnerText.Contains(data.Model.Identity.Name), "Login name missed.");

}

}

自然，Web Server是不可或缺的。幸運的是，分離讓我們的視圖只會涉及最簡單的測試資料，這樣VS內建的簡單Web Server就足夠了。在上面的代碼中，我們直接構造了強型別的TestViewData對象，它包含呈現一個視圖所需要的所有資料：

Cotroller和Action名稱。從理論上說，由不同的Controller和Action進入同樣的視圖可能會得到不同的結果。

View和Master名稱。如果省略，則表明將使用預設的視圖，即通過Controller和Action的值來確定。

ViewData和Model。

TestViewData.GenerateHostUrl方法會把data儲存起來，並返回一個URL。訪問該URL便能夠得到對應的視圖內容。

如果您想使用UnitView，可以從上面的連結中下載UnitView的原始碼和樣本在本機進行嘗試。使用UnitView時主要有以下幾個注意點：

將Tests項目的輸出路徑指向被測試網站的bin目錄，這樣既可以在運行時得到正確的程式集，又不必為網站添加多餘的引用。
將~\UnitView目錄複寫到您的網站根目錄下（在發布網站時，請剔除該目錄）。如果想使用其它目錄，請關注接下來UnitView實現分析。
編輯~\UnitView\Web.config檔案，將MvcApp.Tests.dll修改為您自己的包含測試代碼的程式集。

UnitView實現分析

UnitView組件非常簡單，簡單地幾乎不值一提。TestViewData類型包含了測試需要的所有資料，而TestViewData繼承了TestViewData，提供了強型別的Model屬性訪問方式。它們就不作分析了。

此外，TestViewData還有一些靜態方法：

public class TestViewData

{

static TestViewData()

{

PersistentProvider = new InProcPersistentProvider();

}

public static IPersistentProvider PersistentProvider { get; set; }

public static string GenerateHostUrl(TestViewData data)

{

var key = PersistentProvider.Save(data);

return ViewHostHandlerUrl + "?key=" + HttpUtility.UrlEncode(key);

}

private static string ViewHostHandlerUrl

{

get

{

return ConfigurationManager.AppSettings["UnitView_ViewHostHandlerUrl"]

?? "/UnitView/ViewHostHandler.ashx";

}

}

internal static TestViewData Load(string key)

{

return PersistentProvider.Load(key);

}

...

}

GenerateHostUrl方法將委託PersistentProvider儲存對象，並得到一個key。這個key將拼接在ViewHostHandlerUrl屬性上，這便是被測試的路徑。從代碼中可以看出，如果您不想使用預設的測試路徑，只需在web.config的AppSettings節點中添加一個目標地址即可。

PersistentProvider屬性為IPersistentProvider介面類型，其中定義了Save/Load/Remove三個方法。IPersistentProvider在項目中只有一個實現：InProcPersistentProvider，它會將TestViewData存放在記憶體中的一個字典裡。這個實現已經足夠讓UnitView結合LTAF運行（LTAF的同進程特性起到了關鍵的作用）。不過，如果您還是希望使用WatiN等獨立進程的測試載入器，就必須實現自己的IPersistentProvider類型。例如您可以實現一個FilePersistentProvider，將TestViewData序列化至一個外部檔案中，這樣就可以在合適的時候將它取回了。

另一個較為關鍵的類型是UnitView.Engine.ViewHostHandler：

public class ViewHostHandler : IHttpHandler

{

private HttpContext Context { get; set; }

public void ProcessRequest(HttpContext context)

{

this.Context = context;

ControllerContext controllerContext = new ControllerContext(

new HttpContextWrapper(context),

this.Data.RouteData,

new MockController());

new ViewResult

{

MasterName = this.Data.MasterName,

ViewName = this.Data.ViewName,

TempData = this.Data.TempData,

ViewData = this.Data.ViewData,

}.ExecuteResult(controllerContext);

}

private string Key

{

get

{

string key = this.Context.Request.QueryString["key"];

if (String.IsNullOrEmpty(key))

{

throw new ArgumentNullException("key");

}

return key;

}

}

private TestViewData m_data;

private TestViewData Data

{

get

{

if (this.m_data == null)

{

this.m_data = TestViewData.Load(this.Key);

if (this.m_data == null)

{

throw new ArgumentNullException("Cannot retrieve the data.");

}

}

return this.m_data;

}

}

public bool IsReusable { get { return false; } }

}

首先，在ProcessRequest方法會取回TestViewData，並根據這些資料構造一個ViewResult對象，最後執行它的ExecuteResult方法來輸出視圖內容。由於ExecuteRequest方法的需要，我們還必須構造一個ControllerContext對象，也就意味著我們還必須提供一個Controller對象和HttpContext的封裝。從代碼中可以看出，我們這裡使用了最簡單的資料。由於視圖遵守“約定”，它只會從ViewData中擷取資料，所以無論Controller或HttpContext是什麼值都已經無關緊要了。

您可能會想，為什麼會有這樣的“約定”，不讓視圖從HttpContext對象中擷取資料呢？Mock一個HttpContext對象也不是那麼困難（這裡要感謝各種強大的Mock架構）啊。可惜，Mock後的HttpContext很難進行序列化，這樣就幾乎杜絕了跨進程通訊的可能，這對於使用WatiN和Selenium進行測試的朋友們無疑是一種災難。權衡之下，老趙決定放棄對HttpContext的支援。

注1：目前UnitView基於ASP.NET MVC RC構建，當RTM發布後我會進行必要的更新。請關注老趙這篇文章和託管在MSDN Code Gallery上的代碼（http://code.msdn.microsoft.com/UnitView）。

注2：在《ASP.NET MVC單元測試最佳實務》中我也包含了UnitView組件，實現略有不同——請以本篇文章為主。