在ASP.NET MVC中对控制器进行单元测试是否有真正的价值？

我希望这个问题能提供一些有趣的答案，因为这是困扰我一段时间的问题。

在ASP.NET MVC中对控制器进行单元测试是否有真正的价值？

我的意思是，在大多数情况下（而且我不是天才），我的控制器方法即使在最复杂的情​​况下也是如此：

public ActionResult Create(MyModel model)
{
    // start error list
    var errors = new List<string>();

    // check model state based on data annotations
    if(ModelState.IsValid)
    {
        // call a service method
        if(this._myService.CreateNew(model, Request.UserHostAddress, ref errors))
        {
            // all is well, data is saved, 
            // so tell the user they are brilliant
            return View("_Success");
        }
    }

    // add errors to model state
    errors.ForEach(e => ModelState.AddModelError("", e));

    // return view
    return View(model);
}

大多数繁重的工作都是通过MVC管道或我的服务库完成的。

所以也许要问的问题可能是：

• 对该方法进行单元测试的价值是什么？
• 它不会中断Request.UserHostAddress并ModelState带有NullReferenceException吗？我应该试着嘲笑这些吗？
• 如果我将此方法重新定义为可重复使用的“帮助程序”（考虑到我做了多少次，我可能应该这样做），那么在我真正要测试的大部分都是“管道”时，是否值得进行测试？大概已经被Microsoft测试到寿命不到一英寸了吗？

我认为我的意思确实是，执行以下操作似乎毫无意义，而且是错误的

[TestMethod]
public void Test_Home_Index()
{
    var controller = new HomeController();
    var expected = "Index";
    var actual = ((ViewResult)controller.Index()).ViewName;
    Assert.AreEqual(expected, actual);
}

显然，我对这个夸张的，毫无意义的示例感到困惑，但是有人在这里添加任何智慧吗？

期待它...谢谢。

即使简单，单元测试也有多种用途

1. 信心，所写的符合预期的输出。验证返回正确的视图似乎很琐碎，但结果是客观证据表明已满足要求
2. 回归测试。如果需要更改Create方法，则仍然需要对预期输出进行单元测试。是的，输出可能会随之变化，从而导致测试变脆，但这仍然是对不受管理的变更控制的检查

对于该特定操作，我将测试以下内容

1. 如果_myService为null会怎样？
2. 如果_myService.Create抛出异常，会抛出特定异常来处理该怎么办？
3. 成功的_myService.Create是否会返回_Success视图？
4. 错误会传播到ModelState吗？

您指出了为NullReferenceException检查Request和Model，我认为ModelState.IsValid将负责处理Model的NullReference。

模拟请求可以防止空请求，我认为这通常在生产中是不可能的，但在单元测试中可能会发生。在集成测试中，它将允许您提供不同的UserHostAddress值（就控件而言，请求仍然是用户输入，应进行相应的测试）

我的控制器也很小。控制器中的大多数“逻辑”都是使用过滤器属性（内置和手写）处理的。因此，我的控制器通常只有少量工作：

• 根据HTTP查询字符串，表单值等创建模型。
• 执行一些基本验证
• 调用我的数据或业务层
• 产生一个 ActionResult

大多数模型绑定由ASP.NET MVC自动完成。DataAnnotations也为我处理了大部分验证。

即使测试很少，我仍然通常会编写它们。基本上，我测试是否调用了我的存储库并ActionResult返回了正确的类型。我有一个方便的方法来ViewResult确保返回正确的视图路径，并且视图模型看起来像我期望的那样。我还有另一项检查设置的正确控制器/操作RedirectToActionResult。我还有其他测试JsonResult，等等，等等。

对该Controller类进行子类化的不幸结果是，它提供了许多在HttpContext内部使用的便捷方法。这使得很难对控制器进行单元测试。因此，我通常将HttpContext依赖调用放在一个接口后面，并将该接口传递给控制器​​的构造函数（我使用Ninject Web扩展为我创建控制器）。通常，我在该界面上粘贴帮助程序属性，以访问会话，配置设置，IPrinciple和URL帮助程序。

这需要大量的尽职调查，但我认为这是值得的。

显然，某些控制器比这要复杂得多，但完全基于您的示例：

如果myService引发异常会怎样？

作为旁注。

另外，我会质疑通过引用传递列表的智慧（因为c＃无论如何都是通过引用传递，即使不是，也没有必要）-传递errorAction动作（Action），然后服务可以使用该动作将错误消息发送到然后可以根据需要进行处理（也许想将其添加到列表中，也许想添加模型错误，也许要记录它）。

在您的示例中：

例如，执行（string s）=> ModelState.AddModelError（“”，s）代替ref错误。