为了实现基本的代码覆盖率，我应该针对 ASP.NET MVC 控制器运行哪些测试？
我的控制器正在使用 StructureMap 和 AutoMapper。目前，我的路线没有什么特别之处。对于 基本 CRUD 控制器操作，我应该编写哪些测试来确保良好的代码覆盖范围？
My controllers are utilizing StructureMap and AutoMapper. Presently, there is nothing exceptional with my routes. For the basic CRUD controller actions what tests should I be writing to ensure good code coverage?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在不显示控制器的情况下，很难说出必须在控制器中测试什么。你说它们是基本的CRUD，但后来你谈论了AutoMapper，所以可能没有那么简单。这是单元测试 我编写了 控制器 正在测试中。
It is difficult to say what you have to test in your controllers without showing them. You say they are basic CRUD but then you talk about AutoMapper, so probably it's not as simple as that. Here's an example of unit test I wrote and the controller being tested.
我最近也一直在做同样的事情。根据我的研究，最佳实践似乎是为每个操作创建至少一个测试（这样您就可以通过您的操作通常基于 CRUD 来覆盖 CRUD）并将测试限制为内部代码。这意味着不要跨越方法边界，而是模拟您的操作所需的一切并断言所需的结果。当然，这意味着您需要对服务、存储库等执行相同的操作，
但这意味着您有一个单元测试，如果您更改操作和数据库之间的某些代码，该单元测试不会中断，除非您需要进行更改。这很耗时，但到目前为止，我发现这种努力是值得的，因为不相关代码中的单元测试失败意味着我需要进行更改以让我忘记，或者我耦合得太紧密。
I have been doing the same thing recently. From my research it seems that best practice is to create at least one test for each action (That way you cover CRUD by virtue of the fact that your actions are generally based on CRUD) and limit the test to the internal code. What that means is don't cross the method boundary but rather mock out everything your action needs and assert the desired results. Of course this means that you need to do the same thing for your services, repositories etc
But it means that you have a unit test that won't break if you change some code between the action and the DB unless you have a change to make. It is time consuming but so far I have found the effort well worth it as a failed unit test in unrelated code means I have a change to make I forgot about or I am too tightly coupled.