3

当我设计 MVC 应用程序时，我通常会尝试将几乎所有逻辑（尽可能）排除在我的应用程序之外。我尝试将其抽象为与我的存储库和域实体接口的服务层。

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

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

因此，假设我对我的服务进行了良好的覆盖测试，并且我的操作方法像上面的示例一样简单，那么对这些控制器方法进行单元测试是不是有点矫枉过正？

如果您确实为看起来像这样的方法构建单元测试，那么您从测试中获得了什么价值？

4

1 回答 1

7

如果您确实为看起来像这样的方法构建单元测试，那么您从测试中获得了什么价值？

您可以进行断言的单元测试：

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

单元测试与断言应用程序的正确性一样有助于重构。帮助您确保即使更改代码后结果也保持不变。

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

绝对为 IMO 增值了 3 种非常简单的方法，每个方法的编写时间不会超过几分钟。

于 2012-05-31T20:20:00.877 回答