Unit testing 集成和验收测试的效率陷阱（自动化）

单元测试的优点对我来说是显而易见的，它们是由开发人员自己完成的（测试或代码优先），并且是自动化的

我有点不确定的是，当团队已经由一个专门的测试人员组成时，开发人员是否也应该进行集成测试，这个测试人员会尽可能地自动化整个系统并进行黑盒测试（端到端测试或更常见的验收测试）

有关简短的背景信息和更多详细信息：

集成测试示例（MVC webapp）

• 设置：在测试设置期间，仅引导控制器本身和控制器下面的层。没有任何东西是被嘲弄或存根的
• 测试入口：裸控制器，大多数情况下控制器入口点是带有参数的方法（例如Spring MVC），可以在本地执行。测试夹具期间不涉及浏览器
• 断言目标：模型数据和视图名称被断言为直接输出。也可以断言间接输出（例如写入数据库的数据）。呈现的负载（通常是HTML）被完全忽略

验收测试示例（MVC webapp）

• 设置：整个webapp都是引导的（就像从最终用户那里看到的一样）
• 测试条目：HTTP调用本身。浏览器可以作为测试执行者参与（例如）
• 断言目标：测试输出是完整的呈现响应（HTML和其他工件，如javascript）。还可以包括数据库上的断言（例如插入的数据）

陷阱双重测试（集成+验收） 当包含这两种测试样式时，我看到了主要问题：

• 控制器测试接近一般系统行为（例如提交登录表单、密码验证、成功登录）。这与验收测试非常接近。最终可能会发生“双重测试”，这是非常低效的
• 控制器是更多的白盒测试，并且往往很脆弱，因为它们依赖于较低层的许多依赖关系（与非常细粒度的单元测试不同）。由于这种设置维护控制器测试的工作量很大，所以在整个应用程序作为黑盒启动的情况下进行验收测试更简单，并且更接近生产

以上两点导致了我的结论，即如果您的测试人员具有良好的自动化策略，您应该跳过由开发人员完成的集成测试。他们应该更加关注单元测试

你觉得怎么样？你能解释一下你的测试策略吗？你是否有好/坏的经历，包括两种测试方式

感谢您阅读我的长问题；）

---

编辑：验收测试似乎是端到端更常见的术语，因此我切换了术语。

集成测试（以及，实际上，单元测试）也通过系统测试测试，通过缩小缺陷的位置，有助于调试。如果您的系统有组件A-B-C且未通过系统测试用例，但组件A-B通过了类似的集成测试用例，则缺陷可能在组件C

中，我们在我的工作中接受TDD

当我刚开始工作时，有人告诉我，只要工作能够及时、可预测地完成，我就可以实施我想要的任何政策。在过去做过单元测试之后，我意识到我们经常遇到的问题之一是集成bug。有些可能需要相当长的时间来修复，而且往往是一个惊喜。在扩展应用程序的功能时，我们会遇到我们引入的一些微妙的错误

我决定通过更多地关注我们应该提供的最终结果特性来避免我在过去遇到的那些问题。我们将编写测试验收行为的测试，不仅在单元级别，而且在整个系统级别。我之所以想这样做，是因为在一天结束时，我不关心设备是否正常工作，而是关心整个系统是否正常工作。我们发现进行自动化验收测试有以下好处

• 我们从不回归最终用户功能，因为它是经过明确测试的
• 重构更容易，因为我们不必更新大量的单元测试。我们只需要确保我们的验收测试仍然通过
• 隐含地涵盖了“单元”的集成
• 测试成为所需最终用户功能的非常明确的定义
• 集成问题在更早的时候就暴露出来了，因此也就不那么令人惊讶了

这样做的一些权衡

• 就模拟、存根、固定装置等的使用而言，测试可能更加复杂
• 测试对于缩小哪个“单元”存在缺陷的范围来说用处不大

我们还通过一个持续集成服务器使我们的测试套件可以运行，该服务器为部署标记和包。它与大多数CI设置一样，在每次提交时都会运行

关于你的观点/关切：

设置：整个webapp是 自举（就像人们看到的那样） 来自最终用户）

我们倾向于做的一个折衷是在单元测试的同一进程空间中运行测试。我们的入口点是应用程序堆栈的顶部。我们不必费心尝试将应用程序作为服务器运行，因为这增加了复杂性，并且在覆盖率方面没有增加多少

测试条目：HTTP调用本身。浏览器 可以作为测试执行者参与（例如。 硒）

我们所有的自动化测试都是由一个模拟HTTP GET、POST、PUT或DELETE的程序驱动的。不过，我们实际上并不使用浏览器来实现这一点，在应用程序堆栈的顶部调用特定HTTP调用的映射方式就可以了

断言目标：测试输出是 完整的呈现响应（HTML和 其他工件（如javascript）。 数据库上的断言（例如获取的数据 插入）也可以包括在内

我认为