为什么不赞成测试MVC视图？

我目前正在为ASP.Net MVC应用程序奠定基础，并且正在研究应该准备编写哪种单元测试。我已经在多个地方看到人们在本质上说：“不要打扰测试您的观点，没有逻辑，这是微不足道的，将被集成测试所涵盖”。

我不明白这如何成为公认的智慧。集成测试的目的与单元测试的目的完全不同。如果我中断了某些事情，我不想在半小时后的集成测试中断时就知道，我想立即知道。

示例场景： 假设我们正在与一个Customer实体一起处理标准的CRUD应用。客户有名字和地址。在每个测试级别，我都想验证客户检索逻辑是否正确获取名称和地址。

为了对存储库进行单元测试，我编写了一个集成测试来访问数据库。为了对业务规则进行单元测试，我模拟了存储库，为业务规则提供适当的数据，并验证是否返回了预期的结果。

我想做的是： 为了对UI进行单元测试，我模拟了业务规则，设置了预期的客户实例，渲染了视图，并验证视图是否包含我指定的实例的适当值。

我要做的事情： 要对存储库进行单元测试，我编写了一个集成测试，设置了适当的登录名，在数据库中创建了所需的数据，打开浏览器，导航到客户，并验证结果页面是否包含适当的内容我指定的实例的值。

我意识到上面讨论的两种情况之间存在重叠，但是关键的区别在于设置和执行测试所需的时间和精力。

如果我（或另一个开发人员）从视图中删除了地址字段，则我不想等待集成测试发现这一点。我希望在每天多次获取的单元测试中被发现并标记出来。

我感到我只是没有掌握一些关键概念。有人可以解释为什么要对MVC视图的有效性立即进行测试反馈是一件坏事吗？（或者，如果还不错，则不是获得所说反馈的预期方式）

简单的UI测试在ASP.NET MVC中非常容易。本质上，您要做的只是断言返回的HTML包含您需要的元素。尽管这可以确保HTML页面按照您期望的方式进行结构化，但它不能完全测试UI。

正确的Web UI测试要求使用Selenium之类的工具，该工具将使用计算机上的浏览器并确保JavaScript和HTML在所有浏览器中均能正常工作。Selenium确实具有客户端/服务器模型，因此您可以拥有一组带有Unix，Mac和Windows客户端的虚拟机以及这些环境通用的浏览器。

现在，一个设计良好的MVC（模式，而不是框架）应用程序将重要逻辑放入模型和控制器中。简而言之，当您测试这两个方面时，即会测试应用程序的功能。视图往往仅具有显示逻辑，并且可以通过视觉检查轻松检查。由于视图中的精简处理和经过良好测试的应用程序的大部分，许多人并不认为测试视图层的痛苦大于其所获得的好处。

也就是说，MVC确实具有一些不错的功能来检查请求返回的DOM。这大大减轻了测试视图层的痛苦。

我不会说这不满意。相反，这种感觉是由于对MVC视图（至少是aspx种类）进行单元测试非常困难的结果，因为aspx视图对WebForms的依赖过多，而WebForms本身却是不可测试的。因此，有观点认为，不值得付出努力，因为观点往往没有那么复杂。

当然，视图可能会变得非常复杂，因此由您选择。

我不确定它是否会皱眉。可测试性是使用ASP.NET MVC的主要优势之一。请查看Steve Sanderson的博客，以获取有关此内容的更多信息。

他还在那里写下了最好的ASP.MVC书（IMO）。他不仅会教MVC，而且还会继续教授有关MVC的最佳实践，包括测试实践。

我认为我需要对单元测试视图进行澄清-您可以围绕从控制器返回的结果（ActionResult等）构建单元测试。您仍然需要对实际的UI和UI交互进行其他测试。

您可以通过以下网址了解如何测试控制器操作返回的视图，如何测试控制器操作返回的视图数据以及如何测试一个控制器操作是否将您重定向到第二个控制器操作，在有关在MVC中测试视图数据的这篇简短文章中进行介绍。