【发布时间】：2010-12-02 18:57:34
【问题描述】：
我的应用程序已经有域层的单元测试我想知道单元测试控制器的优点/缺点是什么
以及在测试控制器时应该编写哪些测试用例。
谢谢
【问题讨论】：
标签： asp.net-mvc unit-testing controller
【发布时间】：2010-12-02 18:57:34
【问题描述】：
视情况而定。
验证、重定向、临时消息等可以发生在控制器中。您可能会争辩说，应该像测试模型一样测试这些操作。
另一方面，您应该以“Fat Model, Skinny Controller”的心态为目标。我倾向于确保我的控制器尽可能地愚蠢。围绕您关心的功能（Selenium、Cucumber 等）进行一些端到端测试，这些测试将强制您的控制器是正确的。假设我们正在开发一个功能来列出一些项目。如果此功能的端到端测试没问题，则控制器没问题。如果这打破了你会知道你已经引入了回归。结合这一点，我只有测试来检查正确的视图是否被渲染并发生正确的响应——重定向、json 等......任何more testing on your controller 并且你的逻辑在错误的地方。
在史蒂夫·桑德森的ASP.NET MVC2 中，他对上述推理提出了一些很好的观点。我完全推荐它。没有这些简单的控制器测试的缺点是我可以轻松地打开您的代码库，进行简单的更改并破坏您的应用程序。只要出现正确的视图/响应，应用程序的功能仍然完好无损。
我应该补充一点，在具有正确参数的控制器中调用服务是非常简单的，而且无论您是否间接测试控制器，您都可以快速执行此操作。我总体上倾向于这种方法。所以你的问题的完整答案是肯定的，测试你的控制器；）
【讨论】：
一个“专业”的想法：
如果您将可量化的数据或参数从控制器传递到视图。
在某些情况下，尽管我认为有限或很少见，但在支持代码测试未涵盖的控制器内测试内部逻辑。虽然有人认为应该移动这些代码。
一个“骗局”的想法：
如果您对控制器的测试没有添加任何额外的代码覆盖率或重复测试覆盖率，那么它只会增加开销并增加开发时间而没有任何好处。
【讨论】：
一些可能值得在控制器动作中测试的东西：
- 在视图模型中返回的 UI 逻辑（例如可见性、下拉列表值等）
- 重定向（例如，登录到主页的用户会被重定向到其他页面）
- 验证/警报
【讨论】：
即使您应该始终努力将业务逻辑排除在控制器之外，但在某些情况下，视图模型的构建可能非常复杂，以至于很容易值得测试。
例如，当显示具有多个选择菜单的视图时，这些选择菜单由通过自定义视图模型对数据库进行的复杂 linq 查询填充。那种逻辑不是业务逻辑，放在业务层好像不太对。另一方面，它需要进行测试。
编辑：为了澄清，我并不是说将选择查询放在您的视图中。这将验证 MVC 模式。我的意思是一个控制器，它执行此类查询并使用视图显示的结果构建复杂的自定义视图模型。
【讨论】：
-
视图应该不知道您的查询是什么 - 结果是。视图根本不应该与数据库绑定。
-
+1 坦率地评论说，在某些情况下选择正确视图或 viewModel 的逻辑可能非常复杂，值得测试。
-
@Finglas：似乎有一个误解：我的观点对查询一无所知。这正是控制器使用查询结果构建自定义视图模型的原因。
我发现测试控制器的一个问题是，在某些情况下，您必须模拟 ASP.NET MVC 遵循的执行链才能真正测试您的控制器。
例如，如果您的 OnExecuting 方法中有代码，您需要在单元测试期间在控制器中执行实际操作方法时找到一种方法来触发该方法。
【讨论】：