ASP.NET MVC单元测试：HttpContext类的Path属性解惑-51CTO.COM

有关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属性原理

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

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

估计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 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.

以上内容是从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);  
1.
2.
3.
4.
5.
6.
7.
8.

这里还是使用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);  
1.
2.

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

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

这样您会发现，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;  
    }  
}  
 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.

于是我们就可以更方便地进行相关的单元测试。例如，我们“象征性”地测试一下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);  
}  
 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.

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

以上就是对HttpContext类的Path属性的问题解惑。本文来自老赵点滴：《在单元测试时指定HttpContext的各种Path》

【编辑推荐】