我们是否只在ASP.Net MVC应用程序中测试Contoller类？

Question

我想以最好的方式创建这个Web应用程序。我遇到的所有单元测试示例仅适用于控制器。我理解这些观点很难测试，也许模型层需要像DBUNit这样的东西。你有什么想法？

Answer 1

这是重点;您将视图与应测试的代码分开。但是你应该测试任何“有趣”的逻辑，无论是在控制器或服务层等等。

Answer 2

您可以测试Routes。

Answer 3

您的应用程序中未经测试的任何内容最有可能是错误的（或在某些更改后出现错误）。另一方面，你将无法测试所有东西。

通常做的是测试更重要且更可能包含错误的内容。

控制器可能包含错误，一旦它们通常包含一些逻辑，并且在运行程序时不容易捕获错误。我相信几乎任何不可视的东西都更容易包含错误，但通常更容易测试。

UI通常在开发的早期阶段（仅运行应用程序并查看正在发生的事情是一种测试）进行手动测试，并且通常难以自动测试。但是如果你有一个Web应用程序，并担心它在各种浏览器和分辨率上运行良好，我会建议一些Selenium测试。

但通常情况下，提出几个问题是有用的：“如果这部分中存在错误，那么我有多么紧张 [criticality] ？这部分容错的可能性 [风险] ？测试这部分有多难 [测试开发时间] ？让测试保持最新 [测试维护时间] < / STRONG>？”。这些问题的答案可能是决定测试内容的一个很好的起点。

Answer 4

对于是否应该测试视图，您会得到不同的意见。很多人会争辩说，由于UI往往会频繁变化，因此对视图的单元测试很脆弱，造成的伤害大于好处。其他人则认为所有必须经过单元测试，包括视图。

就仅测试控制器而言，这可能是一个坏主意。应用程序中最重要的部分是域，应该是大多数业务逻辑所在的位置，因此必须进行测试。还应测试数据访问，服务等等（并且可能不会驻留在您的控制器中）。

简而言之，不，控制器不是唯一需要进行单元测试的东西。但是，您可能无法单独测试您的观点。

Answer 5

您应该测试可以测试的一切。除了视图（aspx和ascx文件）之外，它几乎包含了所有其余的代码。

目前，MVC中的“M”通常被理解为 ViewModel ，这是一种具有有限（和自包含）行为的哑数据结构。 Controller的一部分职责是从底层的域模型来回映射到ViewModels。

您也可以使用普通的单元测试框架对您的域模型进行单元测试。

测试驱动开发为您提供最佳保证，确保您获得尽可能高的测试覆盖率。