在一个新的ASP.NET MVC应用程序中，我们遵循TDD方法，使用NUnit进行单元测试，使用Unity进行依赖注入。
通过调整我们的模型以最合适的方式为我们的观点提供数据，我们的观点被视为“愚蠢”。
单位测试我们的观点是否有价值？如果是这样 - 怎么样？
答案 0 :(得分：5)
MVC模式的优点是视图应该非常轻量级，并且不包含需要测试的代码。
如果视图确实包含需要测试的代码，则应将其移出控制器或模型并在那里进行单元测试。
答案 1 :(得分：4)
我本周早些时候刚刚阅读了Justin Etheredge关于ASP.NET MVC测试的一篇好文章。
这是链接： Building Testable ASP.NET MVC Applications
贾斯汀确实在文章的一个小“侧边栏”部分讨论了对视图的测试，并说明了以下内容：
ASP.NET MVC Code-Behind Pages
如果您在最终版本之前关注ASP.NET MVC，您可能已经注意到代码隐藏页面已从框架中删除。这些页面在ASP.NET MVC框架中没有提供任何功能，并且将逻辑放入视图中，而不属于它。视图中包含的任何逻辑都难以测试，就像ASP.NET Web窗体中的代码隐藏文件难以测试一样。
我倾向于同意这一点，因为我会认为“视图”中的逻辑是“气味”的东西，而且，就个人而言，我会寻找一种方法来删除这种逻辑并将其置于控制器内或者更容易测试的模型。
答案 2 :(得分：3)
我还不熟悉ASP.net MVC，但我对MVC模式有很好的了解。一般来说，我会说通过测试你的观点你没有获得更多。通过使用MVC方法，大多数（如果不是全部）域逻辑都驻留在控制器类和业务/服务层类中的业务逻辑中。因此，对服务层进行单元测试应该保证您的业务逻辑得到满足（这是主要目标）。调查您的控制器的进一步测试（如果需要，使用模拟对象进行Http请求）可以保证您的域逻辑正常。
因此，单位测试您的观点对我来说听起来并没有给您带来更多好处。我听说只是与记录器（或类似的框架）的关系进行视图测试，模拟用户点击UI等...
答案 3 :(得分：1)
关于MVC模式的好处是你能够比其他模式（或反模式）单元测试更多的UI层。但是，测试视图实际上不能作为单元测试来完成，因为它需要外部依赖（如浏览器）。
这并不意味着您不应该测试视图，它只是意味着您不能单元测试视图。功能/集成测试仍然是一个好主意。