0

对于我的 ASP.NET MVC3（新）开发，我不想创建对 MvcContrib TestHelper（以及 Rhino Mocks）的依赖，除非它提供了重要的价值。所以我想了解这个助手的当前状态。

文档说 TestHelper 为以下控制器依赖项生成假货：

  • HttpContext
  • HttpRequest
  • HttpResponse
  • HttpSession
  • 形式
  • 临时数据
  • 请求参数
  • 应用路径
  • 路径信息

对于 MVC1 和 MVC2，我可以看到为什么这很有帮助。但是 MVC3 开始引入改进的测试“接缝”，这可能使 TestHelper 的相关性降低。例如，MVC3Request和Response控制器属性专门设计为 HttpRequest 和 HttpResponse 的可隔离/可注入版本。

由于我仍在探索 MVC3 中的可测试性改进，我想知道上面列出的其他依赖项中有多少在 MVC3 中得到了改进的隔离（或可注入性）。我还希望看到代码示例显示在 MVC3 中使用 TestHelper 和不使用 TestHelper 为上述依赖项创建带有假货（存根/模拟）的测试。

如果使用和不使用 TestHelper 的测试编写差异足够小，那么我宁愿放弃 TestHelper ......这意味着我可以自由选择我喜欢的任何隔离框架（MOQ 或NSubstitute）。

最终，当我得知 MVC3 版本针对 HttpRequest 和 HttpResponse 采取了特定改进的可测试性步骤时，我会感到惊讶，但对于上面列出的其他依赖问题却没有。我希望有人可以在不使用 TestHelper 的情况下详细说明上述项目是如何隔离的。

4

1 回答 1

1

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

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

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

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

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

  1. 您创建一个模拟来表示被测主题所依赖的某个对象，并且您可以在单元测试中控制该对象
  2. 您定义对模拟对象的期望
  3. 你调用你正在测试的实际方法
  4. 你断言结果
于 2012-04-13T17:45:40.780 回答