我們繼續《》，今天主要談論HttpContext的依賴問題。

　　在ASP.NET中進行單元測試的天敵便是HttpContext，它是ASP.NET的核心，極端復雜，卻無法進行Mock¹——可見微軟能夠寫出那么龐大的ASP.NET框架真不那么容易?，F在這個狀況改善了不少，因此大家已經可以使用System.Web.Abstractions.dll了，這個程序集中提供了對于HttpContext的抽象，也就是HttpContextBase抽象類。因此在ASP.NET MVC中，各種組件均依賴于HttpContextBase而不是HttpContext。這是一個優秀的做法，大家以后可以盡可能地擺脫HttpContext了。

　　不過這似乎又是一個悖論。雖然已經可以對HttpContext進行Mock（這點增強了可測試性），但是過度依賴HttpContext對于單元測試來說也是一個傷害。這是HttpContext對象的天性所致：它實在太復雜了。您應該已經察覺到，這是個集萬千寵愛于一身的對象，從請求，回復，應用程序，緩存……幾乎包含了Web應用程序需要的所有信息。如果要測試一個依賴于HttpContext的方法，您勢必要為HttpContext的Mock對象填充各種信息——其復雜程度視業務而定。而且，Mock關注的是“行為”，也就是說它關注的是做一件事情所使用“路徑”。那么如果做一件事情可以采用多個路徑又會怎樣？是否需要在測試之前準備好所有的路徑，并且驗證被測試的代碼“采用了，并僅僅采用了其中一條路徑”？因此，Stub慢慢進入人們的視線。Stub關注的是“狀態”……這就是另一個話題了，還會涉及到采用Record & Replay還是Arrange-Act-Assert方式來進行單元測試，暫且不提。

　　之前談到時，老趙曾經談起在視圖中應該只使用ViewData中的數據。這不是第一次說起要放棄HttpContext了，自從有了“抽象”這一有利武器后，一切“不和諧”因素都能夠被分離。試想在MVP模式中，View和Presenter都使用各自的抽象進行交互，一切Web控件，HttpContext等對象都不復存在了，大家眼中只有“數據”和“模型”。同樣，在ASP.NET MVC的Action方法中，也不應該使用HttpContext，這是基于良好的“可測試性”而考慮的。您可能會想，現在的HttpContextBase對象已經可以Mock了啊。沒錯，它的確“可以”，但是這樣做會引起單元測試代碼的膨脹，因為測試代碼中的相當部分必須關注在測試數據的準備，而不是被測試的功能上。對于一個Action方法來說，它關注的應該是用戶與業務邏輯的交互，而不是“如何把HTTP請求轉化為可用的數據”。其實說到底，還是要“分離關注點”。

　　在ASP.NET MVC中負責“轉化數據”的層次為Model Binder。關于這一點，現有的“示例”大都關注把Form或QueryString中的數據轉化為Action參數上，不過Model Binder可用的地方其實更多。例如在《最佳實踐》的代碼中，原本AccountController的Delete方法實現如下：

public ActionResult Delete(string userName)
{
    this.MiddleTier.UserManager.Delete(userName);

    Uri urlReferrer = this.Request.UrlReferrer;
    return this.Redirect(urlReferrer.ToString());
}

　　在刪除了指定對象之后，頁面將跳轉到Url Referrer地址中。在上面的代碼中，這個值將通過訪問Request.UrlReferer來獲得。這就使您的Action方法與HttpContext產生了依賴，因此它的單元測試代碼就需要這樣編寫：

[TestMethod]
public void DeleteTest()
{
    string userName = "jeffz";
    Uri urlReferrer = new Uri("//www.microsoft.com");

    var mockHttpContext = new Mock<HttpContextBase>();
    mockHttpContext.Setup(c => c.Request.UrlReferrer).Returns(urlReferrer);

    var mockController = this.GetMockController();
    mockController.Setup(c => c.MiddleTier.UserManager.Delete(userName))
    .Verifiable();
    mockController.Object.ControllerContext = new ControllerContext(
        mockHttpContext.Object, new RouteData(), mockController.Object);

    mockController.Object.Delete(userName)...
}

　　在單元測試代碼中，我們Mock了一個HttpContextBase對象，讓它的Request.UrlReferrer屬性返回我們準備好的對象，再構造一個新的ControllerContext并交給Controller。而如果我們的UrlReferrer能夠作為Delete方法的參數，那么單元測試代碼就會一下子簡單很多：

[TestMethod()]
public void DeleteTest()
{
    string userName = "jeffz";
    Uri urlReferrer = new Uri("//www.microsoft.com");

    var mockController = this.GetMockController();
    mockController.Setup(c => c.MiddleTier.UserManager.Delete(userName))
   .Verifiable();

    mockController.Object.Delete(userName, urlReferrer)...
}

　　有些朋友可能會問，不就是從Request的UrlReferrer屬性中取值嗎？我們為什么要構造一個ControllerContext，不能直接設置Controller對象嗎？例如這樣就簡單多了：

mockController.Setup(c => c.Request.UrlReferrer).Returns(urlReferrer);

　　似乎可行，不過您運行的時候就會發現，框架會拋出異常，說只有接口的成員，或可以override的成員才能夠被Mock。沒錯，Controller的Request屬性不是virtual的，無法override。Controller類如此設計是故意的，目的就是限制了可用的路徑。試想，如果您Mock了Controller.Request屬性，但是程序代碼通過Controller.HttpContext.Request進行訪問又怎么辦呢？類似的做法還有對方法重載的設計。一般來說，都會把其中幾個方法委托給其中唯一的方法，而只有那個方法是可以被override的。這樣在編寫測試時，我們僅有的Mock入口便確定了，避免了測試代碼過度了解方法實現的問題。

　　回到正題。如果要讓Delete方法接urlReferrer受參數，那么我們就要編寫Model Binder相關的組件：

public class UrlReferrerModelBinder : IModelBinder
{
    public object BindModel(
        ControllerContext controllerContext,
        ModelBindingContext bindingContext)
    {
        return controllerContext.HttpContext.Request.UrlReferrer;
    }}

　　并使其可以直接運用到Action的參數上：

public class UrlReferrerAttribute : CustomModelBinderAttribute
{
    private static UrlReferrerModelBinder s_modelBinder =
        new UrlReferrerModelBinder();

    public override IModelBinder GetBinder()
    {
        return s_modelBinder;
    }
}

　　于是乎，我們的Delete方法便可寫為：

public ActionResult Delete(string userName, Uri urlReferrer)
{
    this.MiddleTier.UserManager.Delete(userName);
    return this.Redirect(urlReferrer.ToString());
}

　　如今的代碼，無論是應用程序還是框架類庫，都必須考慮“可測試性”這個要求。例如.NET 3.0的WF，由于其可測試性不佳一直為人所詬病。現在我們在編寫程序時，要時刻詢問自己：“這么做方便測試嗎？”考慮到這個問題，可能您就會放心地做出某些抉擇了²。