有关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 */
估计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相关的问题应该已经不会给您造成太大问题了。
以上就是对HttpContext类的Path属性的问题解惑。本文来自老赵点滴：《在单元测试时指定HttpContext的各种Path》
【编辑推荐】
