我最近开始使用 MVC，因为我听说 MVC 的主要优点是它使应用程序可单元测试。在编写了第一个单元测试后，我发现测试内部有很多逻辑的控制器并不总是那么简单（发送确认电子邮件、使用会话、上下文和其他 ASP 网络静态）。编写单元测试比编写功能花费的时间更多，而且我不相信这是有用的。
我很想将业务逻辑移动到“服务”层中，该层消除了所有 ASP Net 静态并且可以轻松测试。然后使用 Selenium 进行集成测试，以测试整个功能。
当测试一个动作非常复杂（尤其是模拟输入和设置环境）时，您是否遇到过这种情况？
您是否找到了一种在控制器中包含业务逻辑的好方法。或者您发现使用服务和控制器代码只是中继服务调用更好？
在我看来，测试控制器更等同于集成测试而不是单元测试。你怎么看待这件事？
你认为单元测试控制器比集成测试有什么优势吗？
我很想将业务逻辑移动到“服务”层中，该层消除了所有 ASP Net 静态并且可以轻松测试。然后使用 Selenium 进行集成测试，以测试整个功能。
这几乎就在这里。如果您的控制器很复杂，那么它们需要重构。他们根本不应该有任何业务逻辑。您可以使用 Mock 框架来模拟服务层并通过这种方式轻松测试您的控制器。
在我看来，测试控制器更等同于集成测试而不是单元测试。你怎么看待这件事？
我不同意这一点。您正在测试您的控制器，以确保它根据您提供的输入返回适当的响应。提供一个不存在的 id？重定向到另一个页面或返回 NotFound 视图。模型状态无效？再次返回相同的视图，等等。
当测试一个动作非常复杂（尤其是模拟输入和设置环境）时，您是否遇到过这种情况？
当您的控制器有很多依赖关系并且它们与它们紧密连接时，就会发生这种情况。除非它是现有代码并且对代码进行更改会带来更多麻烦，否则您应该通过接口或抽象类松散地耦合依赖关系，这使得单元测试变得如此容易。您甚至应该使用 Session、Cache 和类似对象的包装器。
正如@Dismissile 建议的那样，首先你必须重构你的控制器，然后单元测试就会很容易。
您是否找到了一种在控制器中包含业务逻辑的好方法。或者您发现使用服务和控制器代码只是中继服务调用更好？
控制器不是放置业务逻辑的地方。所有的业务逻辑都应该在 Model 类中。控制器的全部职责是与模型对话并将视图、json 或其他任何内容返回给客户端。如果控制器中有复杂的业务逻辑，则应将它们移至模型类。
简单地说，您应该考虑“转储视图..瘦控制器..胖模型”！
在我看来，测试控制器更等同于集成测试而不是单元测试。你怎么看待这件事？
集成测试与单元测试完全不同。在集成测试中，您必须设置应用程序并针对它运行测试用例。在这里，您正在测试每个测试场景中整个应用程序的行为，而不是单个单元。单元测试就是测试类中方法的功能。在单元测试中测试一个类或方法应该独立于其他类或方法。
但问题是在设计应用程序时应牢记单元测试，否则单元测试将变得与集成测试一样困难，当然它根本不是单元测试。
你认为单元测试控制器比集成测试有什么优势吗？
与系统级别相比，在单元级别查找和修复错误非常容易。所以答案是肯定的。
我认为在您的情况下，您有一个具有控制器的应用程序比他们必须做的更多。因此，如果您正在认真考虑单元测试，那么您必须在任何需要的地方重构和松散耦合依赖项，否则编写单元测试根本没有太大的收获。