MVC单元测试控制器的优点

Question

我的应用程序已经对域层进行了单元测试我想知道单元测试控制器的优缺点是什么

在测试控制器时应该编写哪些测试用例。

由于

Answer 1

取决于。

控制器中可能会发生验证，重定向，临时消息等。您可以说这些操作应该像您的模型一样进行测试。

另一方面，你应该瞄准'Fat Model, Skinny Controller'心态。我倾向于确保我的控制器尽可能地笨拙。针对您关注的功能（Selenium，Cucumber等......）进行一些端到端测试，这些将强制您的控制器正确无误。假设我们正在开发一个列出一些项目的功能。如果此功能的端到端测试没问题，控制器就可以了。如果这打破你就知道你已经引入了回归。与此相结合，我只有测试，检查正确的视图呈现和正确的响应发生 - 重定向，json等...任何more testing on your controller，你有错误的逻辑。

在史蒂夫·桑德森的ASP.NET MVC2中，他对上述推理提出了一些很好的观点。我完全推荐它。没有这些简单的控制器测试，我可以轻松打开您的代码库，只需更改并破坏您的应用程序。只要正确的观看/响应发生，应用程序仍将在功能上完好无损。

我应该补充说，在控制器中使用正确的参数调用服务测试是非常简单的，无论是否间接测试控制器，都可以快速执行此操作。我倾向于总体上赞成这种方法。所以对你的问题的完整答案是肯定的，测试你的控制器;）

Answer 2

在控制器操作中可能值得测试的一些事情：

1. 在视图模型中返回的UI逻辑（例如，可见性，下拉列表值等）
2. 重定向（例如，登录到主页的用户会被重定向到其他某个页面）
3. 验证/提醒

Answer 3

'亲'的想法：

如果您将可量化的数据或参数从控制器传递到视图。

在某些情况下，尽管我认为有限或罕见，但要测试控制器内部的逻辑，而不是支持代码测试所涵盖。虽然可以说这些代码片段应该被移动。

'Con'思想：

如果您对控制器的测试没有添加任何额外的代码覆盖率或者重复测试覆盖率，那么它只会增加开销时间而无需获益。

Answer 4

即使您应该始终努力将业务逻辑保留在控制器之外，但通常情况下，视图模型的构造可能非常复杂，因此很容易进行测试。

例如，当显示具有多个选择菜单的视图时，这些菜单通过自定义视图模型对数据库进行复杂的linq查询。这种逻辑不是业务逻辑，因此将其放在业务层中似乎并不正确。另一方面，它需要进行测试。

修改：为了澄清，我并不是指在您的视图中添加选择查询。这将验证MVC模式。我的意思是控制器执行此类查询并使用视图显示的结果构建复杂的自定义视图模型。

Answer 5

我发现测试控制器的一个问题是，在某些情况下，您必须模拟ASP.NET MVC遵循的执行链，以真正测试您的控制器。

例如，如果在OnExecuting方法中有代码，则需要在单元测试期间执行控制器中的实际操作方法时找到触发该方法的方法。