如果HttpContext可以被构造，为什么要模拟它？

Question

在ASP.NET中，我一直以某种方式伪造/模拟/存根HttpContext（在ASP.NET MVC/MonoRail中更容易）。

但是我可以看到，HttpContext本身可以轻松构建，只需要几行代码即可。

var tw = new StringWriter();
var workerReq = new SimpleWorkerRequest("/webapp", @"c:\here\there\wwwroot", "page.aspx", tw);
var context = new HtpContext(workerReq);

如果我们将这段代码封装成类似以下的形式，应该就可以正常运行，甚至可能可以使用它来呈现 ASPX：

using(Simulate.HttpContext()) {
  HttpContext.Current.BlaBla;
}

问题如下：

1. 为什么不应该这样做。
2. 为什么应该这样做。
3. 为什么它没有被广泛使用（事实上，我也记不得任何关于它的帖子）。

我记得有一篇帖子，Phill Haack使用反射技巧构建了HttpContext。
但看起来它并不需要这样做。

祝好，
Dmitriy.

- Dmytrii Nagirniak

Answer 1

虽然对于非常简单的测试来说还可以，但如果要对使用 HttpRequest.Files 的组件进行单元测试，该怎么办呢？就我所知，SimpleWorkerRequest 上没有公共 API 可以让你指定这一点。即使你能找到一个位置来设置 HttpFileCollection 属性，它的构造函数也是 internal 的，因此你甚至无法创建该类型的实例。

HttpRequest.Files 在这方面并不孤立，事实上，使用当前 HttpContext 实现可能会有比能够测试的更多的限制。这时候抽象化就派上用场了。

- Levi

Answer 2

有几种情况需要考虑。

方案一：进行单元测试。您有一个小东西，比如一个管理对缓存访问的类，并显式调用HttpContent.Cache。在这种情况下，模拟上下文以便您可以查看调用情况，以及它们是否按照您预期的方式工作。

方案二：进行集成测试，其中您尝试测试生成复杂页面等大型内容。在这种情况下，按照您找到的方式提供真实的HttpContent对象。这样做会更好地模拟真实运行时环境。

- Steve Cooper

---

模拟也非常适合访问特定的错误条件。 - dbn

Answer 3

可能会管用，但是...

• 首先，我看到了一些路径，在不同的环境中可能会有所不同。
• 其次，它需要像IIS这样的东西吗？
• 创建它需要多长时间？如果我有100个需要它的测试，并且花费1秒钟，那么我的测试运行时间会变长1分钟或更长， 这导致开发人员运行较少的测试。
• 您可以轻松地模拟/设置缓存、请求等来创建测试场景吗？

模拟/存根可能更容易。

编辑

在Mono项目中找到了HttpContext和SimpleWorkerRequest的一些源代码：

• SimpleWorkerRequest.cs
• HttpContext.cs

这些可以更好地了解正在创建的情况。

还发现了一篇可能有帮助的文章：ASP.NET CreateApplicationHost/SimpleWorkerRequest API Hole

这实际上很好地说明了我们需要在应用它们之前了解这些对象中正在发生的事情，而这需要时间。模拟似乎更容易。

- Marek Tihkan

---

路径：我认为它们并没有真正被使用。IIS：我认为也不需要。创建时间：我想它不应该比任何复杂对象的创建时间更长。但最后一点（模拟缓存/请求）是一个好建议。 - Dmytrii Nagirniak