评价MvcContrib TestHelper

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

The documentation说TestHelper产生假货以下控制器依赖性：

HttpContext的
的HttpRequest
的HttpResponse
的HttpSession
表格
TempData的
查询字符串
ApplicationPath
PATHINFO

对于MVC1和MVC2我可以看到这是为什么如此乐于助人。但是MVC3开始引入改进的测试“seams”，这可能使得TestHelper变得不太恰当。例如，MVC3 Request和Response控制器属性专门设计为HttpRequest和HttpResponse的可隔离/可注入版本。因为我仍在探索MVC3中的可测性改进，所以我想知道上面列出的其他依赖有多少在MVC3中获得了改进的隔离（或可注入性）。我还希望看到代码示例展示MVC3中看起来像使用TestHelper进行上述依赖关系WITH和WITHOUT的虚假（存根/模拟）测试。

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

最终我会惊讶地发现MVC3版本已经针对HttpRequest和HttpResponse采取了特定的改进的可测试性步骤，但是对于上面列出的其他依赖性问题则没有。我希望有人能够在不使用TestHelper的情况下分解上述项目的分离情况。

来源

2012-04-13 Brent Arias

但是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引入dependency resolver和提供者，它允许你依赖注入比简单的控制器和其他这样的单元测试那些部分的框架的许多其他部分，其以前很难。例如操作过滤器。

但是在实际的单元测试它不会改变任何东西方面：

您创建一个模拟来表示某个对象被测对象取决于和，你可以在你的单元测试
您定义的嘲笑对象
上的期望，你叫你正在测试
您对结果断言实际的方法

来源

2012-04-13 17:45:40

我不反对使用隔离框架。我主要关心的是MvcContrib TestHelper带走了我的框架选择。例如，我不得不使用Rhino Mocks，例如，我更喜欢MOQ。 – 2012-04-13 17:50:48

@BrentArias，是的，它需要Rhino Mocks。如果您更喜欢Moq，请手动模拟所有依赖关系。你仍然可以做单元测试。我只是喜欢MvcContrib.TestHelper的良好语法和它提供的所有扩展方法。但是，如果你愿意，你当然可以用Moq来实现。你将不得不再努力一点。网上有很多文章说明如何使用Moq（HttpContextBase，HttpRequestBase，HttpResponseBase，...）来模拟这些常见的抽象。 – 2012-04-13 17:52:33

评价MvcContrib TestHelper

回答

相关问题