Testing a MicroProfile or Jakarta EE application

Note	This repository contains the guide documentation source. To view the guide in published form, view it on the Open Liberty website.

Learn how to use MicroShed Testing to test a MicroProfile or Jakarta EE application.

What you’ll learn

You’ll start with an existing REST application that runs on Open Liberty and use MicroShed Testing to write tests for the application that exercise the application in a Docker container.

Sometimes tests might pass in development and testing (dev/test) environments, but fail in production because the application runs differently in production than in dev/test. Fortunately, you can minimize these differences between dev/test and production by testing your application in the same Docker container that you’ll use in production.

What is Docker?

Docker is a tool that you can use to deploy and run applications with containers. You can think of Docker as a virtual machine that runs various applications. However, unlike with a typical virtual machine, you can run these applications simultaneously on a single system and independent of one another.

Learn more about Docker on the official Docker website.

Additional prerequisites

Before you begin, Docker needs to be installed. For installation instructions, refer to the official Docker documentation. You’ll test the application in Docker containers.

Make sure to start your Docker daemon before you proceed.

https://raw.githubusercontent.com/OpenLiberty/guides-common/prod/gitclone.adoc

Try what you’ll build

The finish directory in the root of this guide contains the finished application. Give it a try before you proceed.

First, review the PersonServiceIT class to see what the tests look like:

PersonServiceIT.java

link:finish/src/test/java/io/openliberty/guides/testing/PersonServiceIT.java[role=include]

To try out the application, go to the finish directory and run the following Maven goal to build the application and run the integration tests on an Open Liberty server in a container:

cd finish
mvn verify

This command might take some time to run initially because the dependencies and the Docker image for Open Liberty must download. If you run the same command again, it will be faster.

The previous example shows how you can run integration tests from a cold start. With Open Liberty dev mode, you can use MicroShed Testing to run tests on an active Open Liberty server. Run the following Maven goal to start Open Liberty in dev mode:

mvn liberty:dev

After you see the following message, your application server in dev mode is ready:

**************************************************************
*    Liberty is running in dev mode.

After the Open Liberty server starts and you see the To run tests on demand, press Enter. message, you can press the enter/return key to run the integration tests. After the tests finish, you can press the enter/return key to run the tests again, or you can make code changes to the application or tests. Dev mode automatically recompiles and updates any application or test code changes that you make.

After you’re finished running tests, exit dev mode by pressing CTRL+C in the command-line session where you ran the server.

Bootstrapping your application for testing

Navigate to the start directory to begin.

https://raw.githubusercontent.com/OpenLiberty/guides-common/prod/devmode-lmp33-start.adoc

Wait for the To run tests on demand, press Enter. message, and then press the enter/return key to run the tests. You see that one test runs:

 Running integration tests...

 -------------------------------------------------------
  T E S T S
 -------------------------------------------------------
 Running io.openliberty.guides.testing.PersonServiceIT
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 s - in io.openliberty.guides.testing.PersonServiceIT

 Results:

 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

 Integration tests finished.

To begin bootstrapping, import the MicroShedTest annotation and annotate the PersonServiceIT class with @MicroShedTest. This annotation indicates that the test class uses MicroShed Testing.

The PersonServiceIT class outlines some basic information that informs how MicroShed Testing starts the application runtime and at which URL path the application is available:

Replace the PersonServiceIT class.
src/test/java/io/openliberty/guides/testing/PersonServiceIT.java

PersonServiceIT.java

link:hotspots/src/test/java/io/openliberty/guides/testing/PersonServiceIT.1.java[role=include]

Import the ApplicationContainer class and the Container annotation, create the ApplicationContainer application, and annotate the application with @Container annotation.

The withAppContextRoot(String) method indicates the base path of the application. The app context root is the portion of the URL after the hostname and port. In this case, the application is deployed at the http://localhost:9080/guide-microshed-testing URL, so the app context root is /guide-microshed-testing.

server.xml

link:finish/src/main/liberty/config/server.xml[role=include]

The withReadinessPath(String) method indicates what path is polled by HTTP to determine application readiness. MicroShed Testing automatically starts the ApplicationContainer application and waits for it to be ready before the tests start running. In this case, you’re using the default application readiness check at the http://localhost:9080/health/ready URL, which is enabled by the MicroProfile Health feature in the server.xml configuration file. When the readiness URL returns the HTTP 200 message, the application is considered ready and the tests begin running.

Save your changes to the PersonServiceIT class and press the enter/return key in your console window to rerun the tests. You still see only one test running, but the output is different. Notice that MicroShed Testing is using a hollow configuration mode. This configuration mode means that MicroShed Testing is reusing an existing application runtime for the test, not starting up a new application instance each time you initiate a test run.

Talking to your application with a REST client

With MicroShed Testing, applications are exercised in a black-box fashion. Black-box means the tests can’t access the application internals. Instead, the application is exercised from the outside, usually with HTTP requests. To simplify the HTTP interactions, a REST client is injected into the tests. To do this, you imported the org.microshed.testing.jaxrs.RESTClient annotation, created a PersonService REST client, and annotated the REST client with @RESTClient.

In this example, the PersonService injected type is the same io.openliberty.guides.testing.PersonService class that is used in your application. However, the instance that gets injected is a REST client proxy. So, if you call personSvc.createPerson("Bob", 42), the REST client makes an HTTP POST request to the application that is running at http://localhost:9080/guide-microshed-testing/people URL, which triggers the corresponding Java method in the application.

PersonServiceIT.java

link:hotspots/src/test/java/io/openliberty/guides/testing/PersonServiceIT.1.java[role=include]

PersonService.java

link:finish/src/main/java/io/openliberty/guides/testing/PersonService.java[role=include]

Writing your first test

Now that the setup is complete, you can write your first test case. Start by testing the basic "create person" use case for your REST-based application. To test this use case, use the REST client that’s injected by MicroShed Testing to make the HTTP POST request to the application and read the response.

Replace the PersonServiceIT class.
src/test/java/io/openliberty/guides/testing/PersonServiceIT.java

PersonServiceIT.java

link:hotspots/src/test/java/io/openliberty/guides/testing/PersonServiceIT.1.java[role=include]

Replace the PersonServiceIT class to include the assertNotNull static method and write the test logic in the testCreatePerson() method.

Save the changes. Then, press the enter/return key in your console window to run the test. You see that the test ran again and exercised the REST endpoint of your application, including the response of your application’s endpoint:

[INFO] Building rest client for class io.openliberty.guides.testing.PersonService with base path: http://localhost:9080/guide-microshed-testing/ and providers: [class org.microshed.testing.jaxrs.JsonBProvider]
[INFO] Response from server: 1809686877352335426

Next, add more tests.

Replace the PersonServiceIT class.
src/test/java/io/openliberty/guides/testing/PersonServiceIT.java

PersonServiceIT.java

link:hotspots/src/test/java/io/openliberty/guides/testing/PersonServiceIT.2.java[role=include]

The following tests are added: testMinSizeName(), testMinAge(), testGetPerson(), testGetAllPeople(), and testUpdateAge().

Save the changes, and press the enter/return key in your console window to run the tests.

Testing outside of dev mode

Running tests in dev mode is convenient for local development, but it can be tedious to test against a running Open Liberty server in non-development scenarios such as CI/CD pipelines. For this reason, MicroShed Testing can start and stop the application runtime before and after the tests are run. This process is primarily accomplished by using Docker and Testcontainers.

To test outside of dev mode, exit dev mode by pressing CTRL+C in the command-line session where you ran the server.

Next, use the following Maven goal to run the tests from a cold start:

mvn verify

Running tests from a cold start takes a little longer than running tests from dev mode because the application runtime needs to start each time. However, tests that are run from a cold start use a clean instance on each run to ensure consistent results. These tests also automatically hook into existing build pipelines that are set up to run the integration-test phase.

Sharing configuration across multiple classes

Typically, projects have multiple test classes that all use the same type of application deployment. For these cases, it’s useful to reuse an existing configuration and application lifecycle across multiple test classes.

First, create another test class.

Create the ErrorPathIT class.
src/test/java/io/openliberty/guides/testing/ErrorPathIT.java

ErrorPathIT.java

link:hotspots/src/test/java/io/openliberty/guides/testing/ErrorPathIT.java[role=include]

The ErrorPathIT test class has the same @Container configuration and PersonService REST client as the PersonServiceIT class.

Now, run the tests again outside of dev mode:

mvn verify

Notice that tests for both the PersonServiceIT and ErrorPathIT classes run, but a new server starts for each test class, resulting in a longer test runtime.

Creating a common configuration

To solve this issue, common configuration can be placed in a class that implements SharedContainerConfiguration.

Create the AppDeploymentConfig class.
src/test/java/io/openliberty/guides/testing/AppDeploymentConfig.java

AppDeploymentConfig.java

link:finish/src/test/java/io/openliberty/guides/testing/AppDeploymentConfig.java[role=include]

After the common configuration is created, the test classes can be updated to reference this shared configuration.

Updating the PersonServiceIT class

PersonServiceIT.java

link:hotspots/src/test/java/io/openliberty/guides/testing/PersonServiceIT.2.java[role=include]

Remove the container code from the PersonServiceIT class. Remove import statements for ApplicationContainer and Container and the ApplicationContainer app field.

Next, annotate the PersonServiceIT class with the @SharedContainerConfig annotation that references the AppDeploymentConfig shared configuration class.

Replace the PersonServiceIT class.
src/test/java/io/openliberty/guides/testing/PersonServiceIT.java

PersonServiceIT.java

link:finish/src/test/java/io/openliberty/guides/testing/PersonServiceIT.java[role=include]

Import the SharedContainerConfig annotation and annotate the PersonServiceIT class with @SharedContainerConfig.

Updating the ErrorPathIT class

ErrorPathIT.java

link:hotspots/src/test/java/io/openliberty/guides/testing/ErrorPathIT.java[role=include]

Similarly, replace the ErrorPathIT class to remove the container code. Remove import statements for ApplicationContainer and Container and the ApplicationContainer app field.

Next, annotate the ErrorPathIT class with the @SharedContainerConfig annotation.

Replace the ErrorPathIT class.
src/test/java/io/openliberty/guides/testing/ErrorPathIT.java

ErrorPathIT.java

link:finish/src/test/java/io/openliberty/guides/testing/ErrorPathIT.java[role=include]

Import the SharedContainerConfig annotation and annotate the ErrorPathIT class with @SharedContainerConfig.

If you rerun the tests now, they run in about half the time because the same server instance is being used for both test classes:

mvn verify

Great work! You’re done!

You developed automated tests for a REST service in Open Liberty by using MicroShed Testing and Open Liberty dev mode.

Related Links

Learn more about MicroShed Testing.

View the MicroShed Testing website

https://raw.githubusercontent.com/OpenLiberty/guides-common/prod/attribution.adoc