REST API与代码覆盖率的集成测试

Question

我们已经构建了一个REST API，该API公开了许多业务服务-业务服务可以调用其他平台/实用程序服务来执行数据库读取和写入，执行服务授权等。

我们已经将这些服务作为WAR文件部署在Tomcat中。

我们想使用集成测试套件来测试整个设置，我们也希望将其视为回归测试套件。

在此以及任何可以加速套件开发的工具上执行集成测试的最佳方法是什么？以下是我们认为需要解决的一些要求：

1. 能够定义适用于业务场景的集成测试用例的能力。
2. 在套件运行之前，用测试数据设置数据库。
3. 调用在远程服务器（Tomcat）上运行的REST API
4. 验证数据库后测试执行以验证预期输出
5. 拥有REST API的代码覆盖率报告，以便我们知道在套件覆盖的场景中我们应该有多自信。

Answer 1

在我的工作中，我们最近整合了一些测试套件，以测试我们构建的一些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的代码覆盖率报告，以便我们知道在套件覆盖的场景中我们应该有多自信。
  • 我们不会为集成测试衡量代码覆盖率，而只是为单元测试衡量代码覆盖率，因此在此我无法提供任何建议。

请留意我们的技术博客，因为将来可能会有更多细节。