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

Integration Test of REST APIs with Code Coverage

提问by Wand Maker

We have built a REST API that exposes bunch of business services - a business service may invoke other platform/utility services to perform database read and writes, to perform service authorization etc.

我们构建了一个 REST API，它公开了一堆业务服务——业务服务可以调用其他平台/实用程序服务来执行数据库读写、执行服务授权等。

We have deployed these services as WAR files in Tomcat.

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

We want to test this whole setup using a integration test suite which we would like to also treat as regression test suite.

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

What would be a good approach to perform integration testing on this and any tools that can speed up the development of suite? Here are few requirements we think we need to address:

对此以及可以加快套件开发速度的任何工具执行集成测试的好方法是什么？以下是我们认为需要满足的一些要求：

1. Ability to define integration test cases which exercise business scenarios.
2. Set up the DB with test data before suite is run.
3. Invoke the REST API that is running on a remote server (Tomcat)
4. Validate the DB post test execution for verifying expected output
5. Have code coverage report of REST API so that we know how confident we should be in the scenarios covered by the suite.

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

回答by theon

At my work we have recently put together a couple of test suites to test some RESTful APIs we built. Like your services, ours can invoke other RESTful APIs they depend on. We split it into two suites.

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

---

---

• Suite 1 - Testing each service in isolation
  • Mocks any peer services the API depends on using restito. Other alternatives include rest-driver, wiremock, pre-cannedand betamax.
  • The tests, the service we are testing and the mocks all run in a single JVM
  • Launches the service we are testing in Jetty

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

I would definitely recommend doing this. It has worked really well for us. The main advantages are:

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

• Peer services are mocked, so you needn't perform any complicated data setup. Before each test you simply use restito to define how you want peer services to behave, just like you would with classes in unit tests with Mockito.
• The suite is super fast as mocked services serve pre-canned in-memory responses. So we can get good coverage without the suite taking an age to run.
• The suite is reliable and repeatable as its isolated in it's own JVM, so no need to worry about other suites/people mucking about with an shared environment at the same time the suite is running and causing tests to fail.

• 对等服务是模拟的，因此您无需执行任何复杂的数据设置。在每次测试之前，您只需使用 restito 来定义您希望对等服务的行为方式，就像您使用 Mockito 在单元测试中使用类一样。
• 该套件速度非常快，因为模拟服务可以提供预制的内存响应。因此，我们可以获得良好的覆盖范围，而无需套件运行时间。
• 该套件可靠且可重复，因为它隔离在它自己的 JVM 中，因此无需担心其他套件/人员在套件运行的同时使用共享环境并导致测试失败。

---

---

• Suite 2 - Full End to End
  • Suite runs against a full environment deployed across several machines
  • API deployed on Tomcat in environment
  • Peer services are real 'as live' full deployments

• 套件 2 - 完整的端到端
  • 套件针对跨多台机器部署的完整环境运行
  • API部署在环境中的Tomcat上
  • 对等服务是真正的“实时”完整部署

This suite requires us to do data set up in peer services which means tests generally take more time to write. As much as possible we use REST clients to do data set up in peer services.

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

Tests in this suite usually take longer to write, so we put most of our coverage in Suite 1. That being said there is still clear value in this suite as our mocks in Suite 1 may not be behaving quite like the real services.

该套件中的测试通常需要更长的时间来编写，因此我们将大部分覆盖范围放在套件 1 中。话虽如此，该套件仍然具有明显的价值，因为我们在套件 1 中的模拟可能表现得不太像真正的服务。

---

---

With regards to your points, here is what we do:

关于您的观点，我们的做法如下：

• Ability to define integration test cases which exercise business scenarios.
  • We use cucumber-jvmto define business scenarios for both of the above suites. These scenarios are English plain text files that business users can understand and also drive the tests.
• Set up the DB with test data before suite is run.
  • We don't do this for our integration suites, but in the past I have used unitilswith dbunit for unit tests and it worked pretty well.
• Invoke the REST API that is running on a remote server (Tomcat)
  • We use rest-assured, which is a great HTTP client geared specifically for testing REST APIs.
• Validate the DB post test execution for verifying expected output
  • I can't provide any recommendations here as we don't use any libraries to help make this easier, we just do it manually. Let me know if you find anything.
• Have code coverage report of REST API so that we know how confident we should be in the scenarios covered by the suite.
  • We do not measure code coverage for our integration tests, only for our unit tests, so again I can't provide any recommendations here.

• 能够定义运行业务场景的集成测试用例。
  • 我们使用cucumber-jvm来定义上述两个套件的业务场景。这些场景是业务用户可以理解并驱动测试的英文纯文本文件。
• 在套件运行之前使用测试数据设置数据库。
  • 我们没有为我们的集成套件这样做，但在过去，我使用unitils和 dbunit 进行单元测试，而且效果很好。
• 调用在远程服务器 (Tomcat) 上运行的 REST API
  • 我们使用rest-assured，这是一个很棒的 HTTP 客户端，专门用于测试 REST API。
• 验证数据库后测试执行以验证预期输出
  • 我无法在这里提供任何建议，因为我们不使用任何库来帮助简化此操作，我们只是手动完成。如果你发现任何东西，请告诉我。
• 拥有 REST API 的代码覆盖率报告，以便我们知道我们应该对套件涵盖的场景有多大信心。
  • 我们不衡量集成测试的代码覆盖率，只衡量我们的单元测试，所以我不能在这里提供任何建议。

Keep your eyes peeled on our techblogas there may be more details on their in the future.

请密切关注我们的技术博客，因为将来可能会有更多详细信息。

回答by Tomasz Knyziak

You may also check out the tool named Arquillian, it's a bit difficult to set up at first, but provides the complete runtime for integration tests (i.e. starts its own container instance and deploys your application along with the tests) and provides extensions that solve your problems (invoking REST endpoints, feeding the databases, comparing results after the tests).

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

Jacoco extension generates the coverage reports than can be later displayed i.e. by the Sonar tool.

Jacoco 扩展生成的覆盖率报告可以稍后通过声纳工具显示。

I've used it for a relatively small-scale JEE6 project and, once I had managed to set it up, I was quite happy with how it works.

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