今天主要谈论HttpContext的依赖问题。
在ASP.NET中进行单元测试的天敌便是HttpContext，它是ASP.NET的核心，极端复杂，却无法进行 Mock1——可见微软能够写出那么庞大的ASP.NET框架真不那么容易。现在这个状况改善了不 少，因此大家已经可以使用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());
}
以上是小编为您精心准备的的内容，在的博客、问答、公众号、人物、课程等栏目也有的相关内容，欢迎继续使用右上角搜索按钮进行搜索数据
， 对象
， 测试
， httpcontext赋值
， 单元测试
， 被共享 如何摆脱
， httpcontext
， 依赖分离
一个
如何摆脱酒精依赖、如何摆脱手机依赖症、摆脱手机依赖症app、摆脱依赖的议论文、摆脱依赖的名人事例，以便于您获取更多的相关知识。