Jakarta EE Integration Tests With MicroShed Testing

Last Updated:  December 26, 2020 | Published: November 22, 2019

Integration tests for your Jakarta EE application are essential. Testing the application in a full setup will ensure all of your components can work together. The Testcontainers project provides a great approach to use Docker containers for such tests. With MicroShed Testing you get a convenient way to use Testcontainers for writing integration tests for your Jakarta EE application. This is also true for Java EE or standalone MicroProfile applications.

Learn how to use this framework with this blog post. I'm using a Jakarta EE 8, MicroProfile 3.0, Java 11 application running on Open Liberty for the example.

Project setup for MicroShed Testing

For creating this project I'm using the following Maven Archetype:

Besides the basic dependencies for Jakarta EE and Eclipse MicroProfile, we need some test dependencies also. As MicroShed Testing is using Testcontainers under the hood, we can add the official Testcontainers dependencies for starting a PostgreSQL and MockServer container.

Furthermore, we need JUnit 5 and the MicroShed Testing Open Liberty dependency itself. The Log4 1.2 SLF4J binding dependency is optional but improves the logging output of our tests.

As a result, the full pom.xml looks like the following:

With MicroShed Testing, you can either provide your own Dockerfile or in case of Open Liberty use the extension to have almost zero setup tasks. MicroShed Testing searches for a Dockerfile in either the root folder of your project or within src/main/docker.

In this example, I'm providing a custom Dockerfile:

For this application, I'm using the official Open Liberty extension from MicroShed Testing and therefore just have to configure the Open Liberty server within src/main/liberty. This folder contains a custom server.xml and the JDBC driver:

Jakarta EE application walkthrough

As I don't want to provide a simple Hello World application for this example, I'm using an application with JPA & PostgreSQL and an external REST API as a dependency. This should mirror 80% of the basic applications out there.

The application contains two JAX-RS resources: SampleResource and PersonResource

First, you can retrieve a MicroProfile Config property from the SampleResource and a quote of the day. This quote of the day is fetched from a public REST API using MicroProfile RestClient:

Using this public REST API, I'll later demonstrate how to mock this call in your Jakarta EE integration test. The full resource looks like this:

Second, the PersonResource allows clients to create and read person resources. We'll store the persons in the PostgreSQL database using JPA:

Integration test setup with MicroShed Testing

Next, we can set up the integration tests for our Jakarta EE (or Java EE or standalone MicroProfile) application. With MicroShed Testing, we can create a SharedContainerConfiguration to share the Docker containers between integration tests. As our system requires a running application, a PostgreSQL database, and a remote system, I'm creating three containers:

The PostgreSQLContainer and MockServerContainer are part of a Testcontainer dependency. ApplicationContainer is now the first MicroShed Testing class we make use of.  You can use this wrapper for plain Jakarta EE or Java EE applications.

We can set up the ApplicationContainer with any environment variables, we want and provide MicroProfile Config properties in this way.  Next, you can define the readiness path of your application. For this, we can make use of MicroProfile Health and specify the readiness path /health/ready.

Furthermore, MicroShed Testing is capable to override the base URL for our MicroProfile RestClient. This allows us to use the MockServer for our integration tests.

Using the network alias our application is able to communicate with the MockServer and the PostgreSQL database within the Docker network.

Writing integration tests for Jakarta EE applications

Given this setup, we can finally start writing integration tests for our Jakarta EE application. MicroShed Testing can be enabled for a JUnit 5 test using @MicroShedTest. With @SharedContainerConfig you can reference the common system setup.

To test the SampleResource class, I'm expecting to get MicroProfile Config  property configured in the SharedContainerConfiguration. Furthermore, the quotes endpoint should return the quote of the day properly:

Injecting the JAX-RS resource with @RESTClient within the integration test allows us to make the HTTP call like using a JAX-RS client.

The integration test for PersonResource is more advanced. I'm testing the flow of creating a new person and then querying for it:

Summary of MicroShed Testing for Jakarta EE integration tests

Even though the project is in its early stages, it provides excellent support for writing Jakarta EE integrations tests using Testcontainers. There are also dedicated dependencies available for Open Liberty and Payara. With them, it's, even more, simpler to use. You should give it a try and provide feedback to further evolve it.

There are also good examples available for different application setups.

For more information follow this guide on Open Liberty. Furthermore, visit the GitHub repository or the official project homepage. You can find this application also on GitHub.

Have fun writing Jakarta EE integration tests with MicroShed Testing,


{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Sign up for Our Mailing List And Get

the Testing Java Applications ($9) Cheat Sheet for Free

Testing Java Applications Cheat Sheet Cover