在单元测试时指定HttpContext的各种Path

前一段时间有朋友在邮件中向我抱怨，说他们团队在使用ASP.NET MVC开发时，在单元测试的时候总是遇到一些不那么方便的地方。例如，对于HttpContext中各种千奇百怪的Path总是无法掌控。例如某个功能会用到HttpContext的Path属性，有的又要用到RawUrl——有的又会涉及到HostName。于是在单元测试的时候，就可能需要填充Mock对象的多种Path属性，而这几种Path属性的值，在理论上还有关系。这其实还是小事，一个麻烦的事情在于，如果功能实现的方式变了，例如原本使用RawUrl属性，而后来忽然觉得应该使用CurrentExecutionFilePath比较合适，于是单元测试就必须跟着改。如此反复，疲于奔命。

就我个人经验看来，这种情况还是蛮常见的，因为某些时候两种Path属性的值差不多，看上去都可以正常使用，于是刚开始编写的时候可能选择了其中一个。但是后来发现，在另一些情况下两种Path就有区别了，而且应该使用的是另一个属性，于是不得不修改，进而单元测试失败了。于是他问我，有没有什么好方法来“完整而可靠地”设置那些缤繁复杂的Path属性。我之前其实也是根据需求设置各种Path属性，但是这的确不好，最重要的问题在于“单元测试”需要了解太多“被测试方法”的实现细节了，这种依赖非常的不可靠。虽然这也是Mock对象被人诟病的特点之一，但是如果我们能够缓解这个缺陷自然再好不过了。

不过话说回来，在“应对”这个问题之前，您要先了解目前的功能是不是真要访问HttpContext中的各种Path。ASP.NET MVC为了提高程序的可测试性作了很多努力，或者说，将“关注点”进行了很大程度的分离。在大部分情况下，我们都能够不去触及HttpContext，而且我们应该尽可能避免这种情况的发生。例如，对Controller做单元测试的时候直接传递参数，为Model Binder做单元测试的时候使用ValueProvider。想来想去，会直接使用到HttpContext的Path属性的场景不多，可能自定义Route算是一个吧，因为它的功能就是解析URL。

HttpContext的Path属性都是通过HttpRequest对象获得的。而事实上ASP.NET中的HttpRequest对象已经为我们提供一种直接通过URL构造的功能：

var request = new HttpRequest(
    "",                                      /* filename */
    "http://www.cnblogs.com/JeffreyZhao/",   /* url */
    "hello=world");                          /* querystring */

估计ASP.NET开发团队也知道URL是个难办的问题，为我们预留了这样一个构造函数。这时的request对象会预填了大多数Path相关的属性：

request
{System.Web.HttpRequest}
    AcceptTypes: null
    AnonymousID: null
    ApplicationPath: null
    AppRelativeCurrentExecutionFilePath: threw an exception of type 'System.NullReferenceException'
    Browser: null
    ClientCertificate: threw an exception of type 'System.NullReferenceException'
    ContentEncoding: threw an exception of type 'System.NullReferenceException'
    ContentLength: 0
    ContentType: ""
    Cookies: {System.Web.HttpCookieCollection}
    CurrentExecutionFilePath: "/JeffreyZhao/"
    FilePath: "/JeffreyZhao/"
    Files: {System.Web.HttpFileCollection}
    Filter: {System.Web.HttpInputStreamFilterSource}
    Form: {}
    Headers: {}
    HttpMethod: "GET"
    InputStream: {System.Web.HttpInputStream}
    IsAuthenticated: threw an exception of type 'System.NullReferenceException'
    IsLocal: false
    IsSecureConnection: false
    LogonUserIdentity: null
    Params: {hello=world}
    Path: "/JeffreyZhao/"
    PathInfo: ""
    PhysicalApplicationPath: threw an exception of type 'System.ArgumentNullException'
    PhysicalPath: ""
    QueryString: {hello=world}
    RawUrl: "/JeffreyZhao/?hello=world"
    RequestType: "GET"
    ServerVariables: {}
    TotalBytes: 0
    Url: {http://www.cnblogs.com/JeffreyZhao/}
    UrlReferrer: null
    UserAgent: null
    UserHostAddress: null
    UserHostName: null
    UserLanguages: null

以上内容是从Visual Studio的Immediate Window中看到的，由此可以发现，其中大部分的Path属性已经准备好了，但是AppRelativeCurrentExecutionFilePath属性抛出异常（还有两个与本地磁盘路径有关的Path就忽略了），因为它需要特定的虚拟路径环境才能计算出来。通过.NET Reflector观察这个属性的实现，会发现其中牵涉到的内容不是一点两点，几乎不可能通过设置外部环境的方式来使其通过。因此，我们最终还是要通过Mock框架来进行设置——反正我们也需要设置HttpRequest的其它属性，不是吗？

var realRequest = new HttpRequest(
    "",                                      /* filename */
    "http://www.cnblogs.com/JeffreyZhao/",   /* url */
    "hello=world");                          /* querystring */
var mockRequest = new Mock<HttpRequestWrapper>(realRequest) { CallBase = true };
mockRequest
    .Setup(r => r.AppRelativeCurrentExecutionFilePath)
    .Returns("~" + realRequest.CurrentExecutionFilePath);

这里还是使用Moq框架，而Mock的对象则是HttpRequestWrapper类型，而不是我们常用的HttpRequestBase类型。HttpRequestWrapper的特点便是可以“塞入”一个真正的HttpRequest对象，然后把所有成员都委托给这个HttpRequest对象。我们在构建一个Mock<HttpRequestWrapper>对象之后，还需要把CallBase属性设为true，这样便可以让Mock对象在默认情况下直接使用Wrapper的实现了。

有了Request，我们便可以构建一个HttpContext的Mock对象：

var mockContext = new Mock<HttpContextBase>();
mockContext.Setup(c => c.Request).Returns(mockRequest.Object);

但是，Moq框架有个限制，那就是如果您指定了这里的Request对象，再去通过HttpContext指定Request中的其他属性，就会把原来的HttpRequest对象给覆盖。也就是说，下面的代码会让我们对HttpRequest做的努力付之东流：

mockContext.Setup(c => c.Request.Form).Returns(new NameValueCollection());

这样您会发现，mockContext.Object.Request下除了Form外的其他属性都没有值了（或抛出异常，视您Mock时的Behavior是Loose还是Strict而定）。因此，如果我们希望进一步修改HttpRequest中属性的时候，只能直接使用那个Mock<HttpRequestWrapper>对象进行设置。我不清楚其他Mock框架的行为如何，如果您使用的也是Moq框架，可能就只得这么做了。

为了使用方便，我也在测试项目中准备了这样一个辅助方法：

public static class MockHelper
{
    public static Mock<HttpContextBase> MockRequest(string url, out Mock<HttpRequestWrapper> mockRequest)
    {
        int index = url.IndexOf('?');
        string path = index >= 0 ? url.Substring(0, index) : url;
        string queryString = index >= 0 ? url.Substring(index + 1) : "";

        var realRequest = new HttpRequest("", path, queryString);
        mockRequest = new Mock<HttpRequestWrapper>(realRequest) { CallBase = true };
        mockRequest
            .Setup(r => r.AppRelativeCurrentExecutionFilePath)
            .Returns("~" + realRequest.CurrentExecutionFilePath);

        var mockContext = new Mock<HttpContextBase>();
        mockContext.Setup(c => c.Request).Returns(mockRequest.Object);
        return mockContext;
    }
}

于是我们就可以更方便地进行相关的单元测试。例如，我们“象征性”地测试一下ASP.NET Routing中内置的Route类型：

[Fact]
public void URL_Capturing_and_Generation()
{
    // prepare route
    Route route = new Route("{controller}/{action}/{id}", null);

    // Mock request
    string url = "http://www.cnblogs.com/Home/Index/5";
    Mock<HttpRequestWrapper> mockRequest;
    var mockContext = MockHelper.MockRequest(url, out mockRequest);
    mockContext.Setup(c => c.Response.Charset).Returns("utf-8"); // if you need

    // test data capturing
    RouteData routeData = route.GetRouteData(mockContext.Object);
    Assert.Equal("Home", routeData.GetRequiredString("controller"));
    Assert.Equal("Index", routeData.GetRequiredString("action"));
    Assert.Equal("5", routeData.GetRequiredString("id"));

    // test url generation
    var hash = new { controller = "Account", action = "List", id = 1};
    var values = new RouteValueDictionary(hash);
    var requestContext = new RequestContext(mockContext.Object, routeData);
    var pathData = route.GetVirtualPath(requestContext, values);
    Assert.Equal("Account/List/1", pathData.VirtualPath);
}

具体内容就叙述到这里，目前Path相关的问题应该已经不会给您造成太大问题了。

最近因为项目需要，不得不全身心投入ASP.NET MVC相关的东西，每天都会有不少实践和感受。如果您也有某些想法，不妨也一起交流一下。