用集成测试测试控制器
用集成测试测试控制器
提问于 2012-12-06 09:31:06
我从事由3层组成的项目:表示(asp.net mvc) ->业务逻辑->存储库。
我们用单位测试来测试这三个部分。
我们计划增加集成测试。现在我们正在决定应该用它们测试哪一部分。
我们考虑下一步的解决办法：
- 测试控制器，在本例中将涉及系统的所有三个部分。
- 测试业务逻辑，在本例中只涉及两个部分。
如果我们的核心用户寥寥无几，我认为第二种解决方案会带来利润。例如站点，移动版本，命令工具。在这种情况下，所有客户端都将使用经过良好测试的业务逻辑。
你认为什么样的解决方案更好？请描述一下您使用集成测试的经验。
谢谢。
回答 2
Stack Overflow用户
发布于 2012-12-06 09:59:02
我想说你的第一个选择应该是优先选择。如果您要编写跨多个层的进程内测试(即非浏览器自动化)，那么您可以尽可能地从“外部”开始，并尽可能多地通过测试。通过调用控制器来启动您的测试，应该为您的系统的行为提供洞察和保证，给出(例如)意外的或不完整的用户输入。您还可以在操作返回的视图模型上执行断言，从而最大限度地提高测试的相关性和覆盖率。
Stack Overflow用户
发布于 2013-06-18 06:38:28
business logic -> repository:集成测试是必要的，这里发现了许多关键的bug。通过识别错误的SQL查询，这一层还发现了许多与性能相关的错误。
presentation:对控制器测试的反应是混合的。我相信手动或自动测试(通过编码的UI)是必要的，但是UI测试可能不包括所有控制器和业务逻辑。所以目前我们也在为控制器编写测试。进行控制器测试的另一个原因是CodedUI自动化测试或UI手动测试需要大量时间来执行。
首先编写接口集成测试，然后是控制器测试，然后是编码UI。手动测试应该与所有这些活动并行进行。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/13740578
复制相关文章
相似问题
腾讯云开发者
