在单元测试时指定HttpContext的各种Path
2009-08-21 10:02 by 老赵, 6406 visits前一段时间有朋友在邮件中向我抱怨，说他们团队在使用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相关的东西，每天都会有不少实践和感受。如果您也有某些想法，不妨也一起交流一下。
老赵的模板为什么设计成这种样式呢？
正文部分好窄啊，右边菜单栏占了两列。