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

Question

我们已经构建了一个暴露大量业务服务的REST API - 业务服务可以调用其他平台/实用程序服务来执行数据库读写，执行服务授权等。

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

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

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

1. 能够定义执行业务场景的集成测试用例。
2. 在套件运行之前使用测试数据设置数据库。
3. 调用在远程服务器（Tomcat）上运行的REST API
4. 验证DB post测试执行以验证预期输出
5. 拥有REST API的代码覆盖率报告，以便我们了解我们应该对套件所涵盖的方案有多大信心。

Answer 1

在我的工作中，我们最近组建了几个测试套件来测试我们构建的一些RESTful API。与您的服务一样，我们的服务可以调用他们依赖的其他RESTful API。我们把它分成两个套房。

---

• 套件1 - 单独测试每项服务
  • 模拟API依赖于使用restito的任何对等服务。其他替代方案包括rest-driver，wiremock，pre-canned和betamax。
  • 测试，我们正在测试的服务和模拟都在一个JVM中运行
  • 启动我们在Jetty中测试的服务

我肯定会建议这样做。它对我们来说非常有效。主要优点是：

• 对等服务被模拟，因此您无需执行任何复杂的数据设置。在每次测试之前，您只需使用restito来定义您希望对等服务的行为方式，就像使用Mockito进行单元测试时的类一样。
• 套件非常快，因为模拟服务提供预先存储的内存中响应。所以我们可以获得良好的报道，而不需要套件运行年龄。
• 该套件可靠且可重复，因为它独立于其自己的JVM中，因此无需担心其他套件/人员在套件运行的同时与共享环境混淆并导致测试失败。

---

• 套件2 - 完全结束
  • Suite针对跨多台计算机部署的完整环境运行
  • 在环境中的Tomcat上部署的API
  • 同行服务是真实的“实时”全面部署

这个套件要求我们在对等服务中进行数据设置，这意味着测试通常需要更多时间来编写。我们尽可能使用REST客户端在对等服务中进行数据设置。

此套件中的测试通常需要更长时间才能编写，因此我们将大部分内容都放在套件1中。据说这套套件仍有明显价值，因为套件1中的模拟可能与真实服务不同。

---

关于你的观点，以下是我们的工作：

• 能够定义执行业务场景的集成测试用例。
  • 我们使用cucumber-jvm为上述两个套件定义业务方案。这些场景是英文纯文本文件，业务用户可以理解并驱动测试。
• 在套件运行之前使用测试数据设置数据库。
  • 我们不会为我们的集成套件执行此操作，但在过去，我已将unitils与dbunit一起用于单元测试，并且它运行良好。
• 调用在远程服务器（Tomcat）上运行的REST API
  • 我们使用rest-assured，这是一个专门用于测试REST API的优秀HTTP客户端。
• 验证数据库后测试执行以验证预期输出
  • 我不能在这里提供任何建议，因为我们不使用任何库来帮助简化这一过程，我们只是手动完成。如果您发现任何问题，请告诉我。
• 拥有REST API的代码覆盖率报告，以便我们了解我们应该对套件所涵盖的方案有多大信心。
  • 我们不会为集成测试测量代码覆盖率，仅针对我们的单元测试，所以我再也不能在此提供任何建议。

请留意我们的techblog，因为将来可能会有更详细的信息。

Answer 2

您也可以查看名为Arquillian的工具，它最初设置起来有点困难，但为集成测试提供了完整的运行时（即启动自己的容器实例并将您的应用程序与测试一起部署并提供解决问题的扩展（调用REST端点，提供数据库，比较测试后的结果）。

Jacoco扩展程序生成覆盖率报告，而不是稍后显示，即通过声纳工具。

我已经将它用于一个规模相对较小的JEE6项目，一旦我设法建立它，我对它的工作方式非常满意。