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

Posted 2023-02-24

【中文标题】MVC Web 应用程序中的控制器应该是可单元测试的吗？

【英文标题】：Should controllers in MVC web applications be unit-testable?

【发布时间】：2011-03-25 18:31:08

【问题描述】：

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

不过，似乎也有一些 ASP.NET MVC 开发者实际上want their controllersto be unit-testable。

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

【参考方案1】：

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

【参考方案2】：

简答：“是”加“如果”，长答：“否”加“但是”。

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

但是，我仍然倾向于在控制器级别对某些控制流进行一些非常简单的覆盖。它往往更像是一种健全性检查。

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

【参考方案3】：

MVC 模式的最佳特性之一是控制器可以在独立于视图的 html 输出的情况下进行测试。将逻辑与 HTML 输出混合在一起的页面很难测试，这是 MVC 解决的问题之一 - 它使您的控制器完全与逻辑有关，您可以在根本不解析 HTML 的情况下对其进行测试。

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