评估MvcContrib TestHelper

Question

对于我的ASP.NET MVC3 (新的)开发，我不希望创建对MvcContrib TestHelper (因此也是Rhino )的依赖，除非它提供了显著的价值。所以我想了解这个帮手的现状。

文献资料说，TestHelper为下列控制器依赖项生成假货：

• HttpContext
• HttpRequest
• HttpResponse
• HttpSession
• 表格
• TempData
• QueryString
• ApplicationPath
• PathInfo

对于MVC1和MVC2，我可以理解为什么这会如此有用。但是MVC3开始引入改进的测试"接缝“，这可能使TestHelper不那么相关。例如，MVC3 Request和Response控制器属性被专门设计为HttpRequest和HttpResponse的可隔离/可注入版本。

由于我仍然在探索MVC3中的可测试性进展，我想知道上面列出的其他依赖项中有多少在MVC3中获得了更好的隔离(或注入性)。我还希望看到代码示例，这些代码展示了在MVC3中如何使用TestHelper为上面的依赖项创建假测试(存根/模拟)。

如果有和没有TestHelper的测试编写的差异足够小，那么我宁愿放弃TestHelper...which就意味着我可以自由选择任何我喜欢的隔离框架(MOQ或NSubstitute)。

最终，我会惊讶地发现，MVC3发行版为HttpRequest和HttpResponse采取了特定的改进的可测试性步骤，但没有针对上面列出的其他依赖问题。我希望有人能给出一个细分，上面的项目是如何隔离，而不使用TestHelper。

Answer 1

但是MVC3开始引入改进的测试“接缝”，这可能使TestHelper不那么相关。例如，MVC3请求和响应控制器属性被专门设计为可隔离/可注入的HttpRequest和HttpResponse版本。

MVC在单元测试方面并没有对您在问题中列出的对象引入任何新的东西。它们是ASP.NET MVC 1和2中的抽象，也是ASP.NET MVC 3中的抽象。这允许您对依赖于它们的控制器操作和代码进行单元测试。但是为了做到这一点，您需要模拟那些依赖项。这就是一个模仿框架发挥作用的地方。犀牛毛只是一个可能的框架。MVCContrib.TestHelper为单元测试控制器操作提供了非常好的、流畅的语法。就我个人而言，我一直在使用它。它确实使单元测试更具可读性，并避免将它们与各种管道、模拟和基础结构代码相混淆。

检查此单元测试，例如：https://github.com/darind/samplemvc/blob/master/tests/SampleMvc.Web.Tests/Controllers/UsersControllerTests.cs

ASP.NET MVC 3引入了一个依赖解析器和提供程序，它允许您将依赖项注入到框架的许多其他部分，而不是简单的控制器，因此单元测试那些以前很困难的部分。例如，动作过滤器。

但是就实际的单元测试而言，它并没有改变任何事情：

1. 您可以创建一个模拟来表示被测试主题所依赖的、并且可以在单元测试中控制的某个对象。
2. 定义对模拟对象的期望。
3. 调用正在测试的实际方法。
4. 你对结果的断言