MVC Web应用程序中的控制器是否应该是可单元测试的？

Question

在我看来，不同编程语言的Web开发人员经常对此有不同的看法。例如，Ruby Web开发人员（使用Rails作为主导框架）似乎将控制器视为粘合代码，它应该具有功能测试，而不是单元测试。类似的态度在PHP世界中占主导地位，但是有一些主动性（例如Symfony2）。

但是，例如，某些ASP.NET MVC开发人员实际上似乎want their controllers to be unit-testable。

我想知道的是，它是否真的适用于Web开发。控制器是否值得单元测试？将它们设计为可单元测试是否会显着削弱非平凡应用程序的开发速度？此外，是否有任何Web框架试图强制执行控制器单元可测试性？欢迎个人经历。

Answer 1

简短回答：“是”带有“如果”，长句回答：“否”带有“但是”。

这些天我倾向于错过控制器级单元测试，转而支持模型和业务对象的强大单元测试覆盖以及Cucumber的功能测试覆盖。这里假设控制器是非常轻量级的对象，将数据路由到底层模型中，这些模型封装了绝大多数业务逻辑。

但是，我仍然倾向于对控制器级别的某些控制流程进行一些非常清晰的报道。它往往更像是一种理智检查。

控制器级测试的一个问题是，您经常需要模拟或生成大量模型和对象才能进行有效测试。鉴于此，我发现将这些测试推进到功能层更有价值，其中测试风格允许您更有效地表达这些依赖关系（通过明确遵循通过应用程序本身或通过类似系统生成它们所需的步骤黄瓜的声明性规则）。

Answer 2

一切都值得单元测试。在这种情况下，它取决于控制器中实现了多少逻辑...在小型项目中，您可以没有连接外部逻辑，您可能希望在控制器中进行一些数据库操作（如许多Microsoft示例） 。在更大的解决方案中，您可能不需要测试控制器，只要它的工作只是调用指定的业务逻辑方法......这不是关于控制器是否值得进行单元测试，而是关于它们包含的代码是否是......

Answer 3

MVC模式的最佳功能之一是可以通过视图隔离HTML输出来测试控制器。将逻辑与HTML输出混合的页面很难测试，这是MVC解决的问题之一 - 它使您的控制器全部与逻辑相关，您可以在不解析HTML的情况下对其进行测试。

理想情况下，您的控制器将从单独的数据访问类中获取数据，您可以为测试存根，因此您只是测试逻辑。基本上，您将控制器与数据库隔离，就像MVC将其与视图隔离一样 - 然后测试很容易，因为您不需要包含测试数据的数据库。