是否真的有必要测试控制器方法?

Jer*_*ose 3 asp.net-mvc unit-testing asp.net-mvc-3

当我设计MVC应用程序时,我通常尝试将几乎所有逻辑(尽可能多)保留在我的应用程序之外.我尝试将其抽象为一个与我的存储库和域实体接口的服务层.

所以,我的控制器方法最终看起来像这样:

public ActionResult Index(int id)
{
    return View(Mapper.Map<User, UserModel>(_userService.GetUser(id)));
}
Run Code Online (Sandbox Code Playgroud)

因此,假设我有很好的覆盖测试我的服务,并且我的动作方法很简单,就像上面的例子一样,单元测试这些控制器方法是否过度?

如果你为看起来像这样的方法构建单元测试,你从测试中获得了什么价值?

dan*_*wig 7

如果你为看起来像这样的方法构建单元测试,你从测试中获得了什么价值?

您可以使用断言的单元测试:

  1. 调用_userService的GetUser方法,传递传递给控制器​​的相同int.
  2. 返回的结果是ViewResult,而不是PartialViewResult或其他东西.
  3. 结果的模型是UserModel实例,而不是User实例(从服务返回的是实例).

单元测试在重构方面同样有助于断言应用程序的正确性.即使您更改了代码,也可以确保结果保持不变.

例如,假设您有一个更改,当请求是async/ajax时,操作应返回PartialView或JsonResult.在控制器中进行更改的代码不会太多,但是一旦更改代码,单元测试可能会失败,因为您可能没有模拟控制器的上下文来指示请求是否为ajax.因此,这会告诉您扩展单元测试以维护正确性的断言.

对3种非常简单的方法绝对增值IMO,每次写入时间不应超过几分钟.

  • 假设您正在使用依赖注入,测试是否注入了正确的服务实现也很重要. (2认同)
  • @Dmitry,不会是组合root/bootstrapper方法的单元测试,而不是控制器/动作单元测试? (2认同)