我应该测试我的控制器（MVC）吗？

Question

我一直在使用TDD几个月，现在我想了解如何测试我的控制器（MVC）。

单元测试是通过测试每个功能的最小单元进行的。有时候，控制器不小。他们从模型中获取数据，然后传递给视图。

我该如何测试控制器？我应该模拟控制器的依赖关系吗？

控制器测试是否被认为是集成测试？

谢谢。

Answer 1

同样的问题昨天问：

Does it make sense to test controllers

，在我看来 - 是的，它是有意义的测试控制器。您可以：

• 他们身后模拟服务，所以它更容易测试只是控制器本身
• 休假服务unmocked，做集成测试以及

Answer 2

我做TDD相当长的时间。我正在使用ASP.NET MVC进行TDD超过一年的时间。

我以规范的规则开始：“没有没有单元测试的代码行”，所以我测试了一切 - 包括控制器。控制器必须经过测试，这是MVC框架的目标之一 - 让这些东西成为可测试的。

对于那些方法非常好的小应用程序。几乎所有的逻辑都放在控制器内部，一切都很好地测试。

但是只要我继续使用MVC，我就开始改变主意了。我尽量保持控制器尽可能纤薄。理想情况下，只需将调用委托给某个业务对象并包装结果即可。其余的是通过过滤器。

这对我来说也很好！我现在有了单独实施/测试的业务对象，所以控制器就是集成点。没有理由测试集成点，因为它很小。

关于集成测试：我还没有遇到这种情况，我真的需要这种情况。不要忘记，控制器总是依赖于由构造函数注入的抽象。只要你有'好'假设这些抽象如何工作，你创建适当的单元测试。当你失败时，你只需纠正单元测试。

集成测试非常重要且有用，但我尽可能少地创建集成测试。

Answer 3

我采用与Alexander B.相同的方法来控制器，我的控制器很薄很笨。不过，我仍然为它们编写测试，以确保它们正确调用业务或服务对象并传递正确的参数。

这可能是我上周最终发现的一个实际bug最好的说明。我有一个控制器，允许管理员批准或拒绝来自用户的请求，它有两个视图，未完成请求的列表视图和每个请求的详细信息视图。两种观点都可以批准或否认。控制器调用的服务还有一些其他暴露的方法，其中包括更改请求状态的方法...你可以看到这是怎么回事。列表视图称为批准或拒绝并触发工作流的正确方法，细节视图仅称为更改状态方法，并未启动任何进一步的工作流程。这是我的编码错误，但对于我的生活，我无法看到它的历史 - 工作流程在后台线程中运行，并且我花了一周时间浏览那些线程，假设它在该部分中是错误的。

所以对我来说

• 由于作为控制器的其他地方传递数据很快就需要测试。
• 如果需要测试（如果 有人去除哪些检查？）

等

Answer 4

要开发单元测试为您的控制器，自然的方式是你的控制器检查模型的有效性模拟控制器依赖的接口（它控制的'事物'，我们称它们为IControllable s）。然后您可以验证控制器是否按预期的方式操纵受控对象。

如果控制器与受控对象之间的交互较为复杂，则专用集成测试可能有意义。例如，可能会有一系列的类实现IControllable - 这些实现中的每一个都可以很好地与控制器一起工作？也许多个不同IControllables将交互（使用相同的资源）？或者IControllables可能有棘手的方法来配置它们，影响它们的行为？测试这种方法的一种方法是编写一个可重用的测试套件，在其中抽取一系列可疑的实现或其组合。

最后但并非最不重要，TDD约验收测试以及。因此，在进行TDD时，您还将进行高级别的端到端测试，以执行终端用户可以识别的场景。最有可能的是，这些也会锻炼控制器 - 通过这种方式也可以测试控制器和（某些）类之间的正确集成。