MVC 3：测试控制器VS集成测试

Question

我最近刚开始使用MVC，因为我听说MVC的主要优点是它使应用程序单元可测试。在编写了第一个单元测试之后，我发现测试内部有很多逻辑的控制器并不总是很简单（发送确认电子邮件，使用Session，上下文和其他ASP Net静态）。编写单元测试比使用功能需要更多时间，我不相信这是有用的。

我很想将业务逻辑转移到“服务”层，消除所有ASP Net静态，并且可以轻松测试。然后使用Selenium进行集成测试，以测试整个功能。

1. 在测试动作时是否非常复杂（特别是嘲笑输入和设置环境）？

2. 您是否找到了在控制器中使用业务逻辑的好方法。或者您发现使用服务和控制器代码更好地中继服务呼叫？

3. 在我看来，测试控制器更像是集成测试，而不是单元测试。你怎么看待这个？

4. 您认为单元测试控制器是否优于集成测试？

Answer 1

  

我很想将业务逻辑转移到“服务”层   消除所有ASP Net静态并且可以轻松测试。然后   使用Selenium进行集成测试以测试整体   功能。

这就在这里。如果你的控制器很复杂，那么它们需要重构。他们根本不应该有任何业务逻辑。您可以使用Mock框架来模拟服务层并以这种方式轻松测试控制器。

  

在我看来，测试控制器更像是集成   测试比单元测试。你怎么看待这个？

我不同意这一点。您正在测试控制器，以确保它根据您提供的输入返回相应的响应。提供不存在的ID？重定向到另一个页面或返回NotFound视图。模型状态无效？再次返回相同的视图等。

Answer 2

  

在测试操作非常复杂时（尤其是模拟输入和设置环境），您是否遇到过这种情况？

当您的控制器具有大量依赖关系并且它们与它们紧密连接时，会发生这种情况。除非是现有代码并且将更改带入代码会产生更多麻烦，否则应该通过接口或抽象类松散地耦合依赖项，这使得单元可测试变得如此简单。您甚至应该使用Session，Cache和类似对象的包装器。

正如@Dismissile建议的那样，首先你需要重新调整控制器的因子，然后进行单元测试很容易。

  

您是否找到了在控制器中使用业务逻辑的好方法。或者您发现使用服务和控制器代码更好地中继服务呼叫？

控制器不是放置业务逻辑的地方。所有业务逻辑都应该在Model类中。控制器的全部责任是与模型对话并将视图，json或其他任何内容返回给客户端。如果控制器中有复杂的业务逻辑，则应将它们移动到模型类。

只需要考虑“转储视图......瘦控制器......胖模型”！

  

在我看来，测试控制器更像是集成测试，而不是单元测试。你怎么看待这个？

集成测试与单元测试完全不同。在集成测试中，您必须设置应用程序并针对它运行测试用例。在这里，您将测试每个测试场景中整个应用程序的行为，而不是单个单元。单元测试就是测试类中方法的功能。在单元测试中测试类或方法应独立于其他类或方法。

但问题是在设计应用单元时应牢记测试，否则单元测试将变得像集成测试一样困难，当然它根本不是单元测试。

  

您是否认为单元测试控制器优于集成测试？

与系统级别相比，在单元级别查找和修复错误非常简单。所以答案是肯定的。

我认为在你的情况下，你有一个应用程序，控制器比他们必须做的更多。因此，如果您认为单元测试如此严重，那么您必须重新考虑并松散地将依赖关系放在任何需要的地方，否则编写单元测试就没有多大好处。