git clone https://github.com/openliberty/guide-microshed-testing.git
cd guide-microshed-testing
Contents
- What you’ll learn
- Additional prerequisites
- Getting started
- Bootstrapping your application for testing
- Talking to your application with a REST client
- Writing your first test
- Testing outside of dev mode
- Sharing configuration across multiple classes
- Great work! You’re done!
- Related Links
- Guide Attribution
Tags
Testing a MicroProfile or Jakarta EE application
Prerequisites:
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.
Getting started
The fastest way to work through this guide is to clone the Git repository and use the projects that are provided inside:
The start
directory contains the starting project that you will build upon.
The finish
directory contains the finished project that you will build.
Before you begin, make sure you have all the necessary prerequisites.
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
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.
When you run Open Liberty in dev mode, dev mode listens for file changes and automatically recompiles and deploys your updates whenever you save a new change. Run the following goal to start Open Liberty in dev mode:
mvn liberty:dev
After you see the following message, your Liberty instance is ready in dev mode:
************************************************************** * Liberty is running in dev mode.
Dev mode holds your command-line session to listen for file changes. Open another command-line session to continue, or open the project in your editor.
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 thePersonServiceIT
class.src/test/java/io/openliberty/guides/testing/PersonServiceIT.java
PersonServiceIT.java
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
1<server>
2
3 <featureManager>
4 <feature>jaxrs-2.1</feature>
5 <feature>jsonb-1.0</feature>
6 <!-- tag::mpHealth[] -->
7 <feature>mpHealth-3.1</feature>
8 <!-- end::mpHealth[] -->
9 <feature>mpConfig-2.0</feature>
10 <feature>mpRestClient-2.0</feature>
11 <feature>beanValidation-2.0</feature>
12 <feature>cdi-2.0</feature>
13 </featureManager>
14
15</server>
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
PersonService.java
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 thePersonServiceIT
class.src/test/java/io/openliberty/guides/testing/PersonServiceIT.java
PersonServiceIT.java
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 thePersonServiceIT
class.src/test/java/io/openliberty/guides/testing/PersonServiceIT.java
PersonServiceIT.java
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 theErrorPathIT
class.src/test/java/io/openliberty/guides/testing/ErrorPathIT.java
ErrorPathIT.java
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 theAppDeploymentConfig
class.src/test/java/io/openliberty/guides/testing/AppDeploymentConfig.java
AppDeploymentConfig.java
After the common configuration is created, the test classes can be updated to reference this shared configuration.
Updating the PersonServiceIT class
PersonServiceIT.java
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 thePersonServiceIT
class.src/test/java/io/openliberty/guides/testing/PersonServiceIT.java
PersonServiceIT.java
Import the SharedContainerConfig
annotation and annotate the PersonServiceIT
class with @SharedContainerConfig
.
Updating the ErrorPathIT class
ErrorPathIT.java
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 theErrorPathIT
class.src/test/java/io/openliberty/guides/testing/ErrorPathIT.java
ErrorPathIT.java
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.
Guide Attribution
Testing a MicroProfile or Jakarta EE application by Open Liberty is licensed under CC BY-ND 4.0
Prerequisites:
Nice work! Where to next?
What did you think of this guide?
Thank you for your feedback!
What could make this guide better?
Raise an issue to share feedback
Create a pull request to contribute to this guide
Need help?
Ask a question on Stack Overflow