Asp.net 直接使用HttpContext是件坏事吗？

我有一个构建在ASP.Net之上的可供选择的MVC框架（尽管没有严格绑定到它）。我经常处理的事情之一是

HttpContext

实例和

HttpContext.Current

。最近，我尝试为我的框架进行一些单元测试，发现HttpContext是出了名的难以测试。因为我的应用程序不一定与ASP.Net绑定，所以我尝试重新实现HttpContext、HttpRequest和friends的更基本版本，但这对于这些类中必须包含的大量信息来说是一项巨大的任务

---

我到底该怎么办？找到一个使用HttpContext进行测试的变通方法，或者重新构造我的代码，使其不那么依赖HttpContext？还是有更好的办法？直接使用HttpContext是件坏事吗

我完全理解你的痛苦。我花了很多时间在ASP MVC2上

在我自己的奋斗中，我发现了关于单元测试和集成测试的各种讨论。我可以理解这一区别，但我尽可能在尽可能接近生产环境的环境中进行集成测试。我很有可能会因为说这句话而被钉在墙上；我不怕

我尝试了几种不同的方法来模拟单元测试时所需的各种类，包括开源以及TypeMock和Isolator的试用。最后，我找到了一篇专门关于集成测试的文章，它解决了我试图克服的大多数问题。请看这里：

我真的不能说你应该如何构造你的代码。从我在ASP MVC源代码中看到的情况来看，我不明白为什么不应该使用HttpContext，尽管测试它确实很痛苦

---

这有帮助吗？如果您感兴趣，我很乐意与您分享我尝试过的各种解决方案的一些示例。

这个问题似乎很有用：例如，我的框架的某些部分将

HttpContext

作为一个参数。。。或者以某种容量使用

HttpContext.Current

。我更希望能够对这些部分进行单元测试，而不是只进行集成测试