在我的工作中，我们最近整合了一些测试套件，以测试我们构建的一些RESTful API。像您的服务一样，我们的服务可以调用它们依赖的其他RESTful
API。我们将其分为两个套件。
- 套件1-隔离测试每个服务
- 嘲笑该API依赖于使用restito的任何同级服务。其他替代方法包括：休息驱动器，wiremock，预装罐头和betamax。
- 测试，我们正在测试的服务以及模拟都在单个JVM中运行
- 启动我们正在Jetty中测试的服务
我绝对会推荐这样做。它对我们来说真的很好。主要优点是：
- 对等服务是模拟的，因此您无需执行任何复杂的数据设置。在每个测试之前，您只需使用restito定义对等服务的行为方式，就像使用Mockito进行单元测试中的类一样。
- 该套件非常快，因为模拟服务提供了预先设置的内存中响应。因此，我们可以在不花时间运行套件的情况下获得良好的覆盖率。
- 该套件是可靠且可重复的，因为它被隔离在自己的JVM中，因此无需担心其他套件/人们在套件运行的同时嘲笑共享环境，并导致测试失败。
- 套房2-完整的端到端
- 套件针对跨多台机器部署的完整环境运行
- 在环境中的Tomcat上部署的API
- 对等服务是真正的“实时”完整部署
该套件要求我们在对等服务中进行数据设置，这意味着测试通常需要更多时间来编写。我们尽可能使用REST客户端在对等服务中进行数据设置。
该套件中的测试通常需要更长的时间来编写，因此我们将大部分内容都放在套件1中。要说的是，在此套件中仍有明显的价值，因为套件1中的模拟可能无法像真正的服务那样运行。
关于您的观点，这是我们的工作：
- 能够定义适用于业务场景的集成测试用例的能力。
- 我们使用cucumber-jvm为上述两个套件定义业务方案。这些方案是业务用户可以理解并进行测试的英文纯文本文件。
- 在套件运行之前，用测试数据设置数据库。
- 我们在集成套件中不执行此操作，但是在过去，我将unitils与dbunit一起用于单元测试，并且效果很好。
- 调用在远程服务器（Tomcat）上运行的REST API
- 我们使用rest-assured，这是一个出色的HTTP客户端，专门用于测试REST API。
- 验证数据库后测试执行以验证预期输出
- 我在这里无法提供任何建议，因为我们没有使用任何库来简化此过程，我们只是手动进行。让我知道您是否找到任何东西。
- 拥有REST API的代码覆盖率报告，以便我们知道在套件覆盖的场景中我们应该有多自信。
- 我们不会为集成测试衡量代码覆盖率，而只是为单元测试衡量代码覆盖率，因此在此我无法提供任何建议。
请留意我们的技术博客，因为将来可能会有更多细节。
