Warning: A non-numeric value encountered in /home/guillerm/public_html/wp-content/themes/Builder-Cohen/lib/builder-core/lib/layout-engine/modules/class-layout-module.php on line 499

OpenDJ Java SDK Testing: Part 2

A few weeks back I decided to write a blog post on how to efficiently test a Java application that uses the OpenDJ SDK to connect to an LDAP store (read post here). Since the scope was so big I had to break it down into two smaller posts. In this second part I will walk you through a sample maven-based application written in Java that uses Docker for integration testing.

The following diagram illustrates the application build process:


The sample app follows the standard Maven Build Life Cycle but it adds a couple of phases to it so that we can build, run and destroy a Docker container before the Integration Test Phase.

About the Sample App

You can download the sample application from my Github repo.

The application uses the OpenDJ Java SDK to retrieve User objects from a Directory Server and perform operations on them (create, update, and delete). The code is pretty straight forward so feel free to explore it if you want to understand how it works. However, in this post I am just going to focus on testing the Person Data Access Object (PersonDAO.java). The interface is self-explanatory:

Unit vs Integration Testing

The sample app uses JUnit for both unit and integration testing. To distinguish between these two types of test classes we will use JUnit categories. This will also allow us to link each test to a different build phase.

The IntegrationTest interface is an empty interface that will be used as a marker class:

Use the following annotation to add a test class to the IntegrationTest category:

Now that you know how to mark your tests we need to tell the maven-surefire-plugin to skip all the annotated classes during the test phase so that only unit tests get executed:

Similarly we need to configure the maven-failsafe-plugin to only execute annotated classes during the integration-test phase:

The sample application only has one unit test  (PersonDAOUnitTestCase) and one integration test (PersonDAOIntegrationTestCase). Both classes extend from a base class called AbstractPersonDAOTestCase that implements most of the logic. The only difference between these two classes is how they initialize the LDAP connection. While PersonDAOUnitTestCase uses an in-memory backend, PersonDAOIntegrationTestCase establishes a “real” connection to an external LDAP server (in this case it will connect to a Docker container).

Sample Unit Test

PersonDAOUnitTestCase makes use of the Memory Backend provided by the OpenDJ SDK. In other words, it won’t actually connect to an external LDAP server. In Part 1 I talked about this feature extensively.

Sample Integration Test

For integration testing the idea is to spin up a Docker container running OpenDJ, execute the integration tests, and stop the container when the tests are done. The question is, how can we integrate this process into the maven build lifecycle? Well, we could write our own custom plugin…Luckily somebody has done all the hard work for us. This docker-maven-plugin does exactly what we need, and it works great. Here is how it works.

First we need to find a place to store the Dokerfile and all it’s dependencies such as LDIF and schema files. I will use the same artifacts from one of my previous post. You can find these files in the following location:

project screenshot

Time to add the docker-maven-plugin to our pom.xml. The plugin will get invoked three times during the build process:

  • build-images: executes the Dockerfile and build the image.

  • start-containers: starts the container.

  • stop-containers: stops and destroys the container.

If you are familiar with Docker you’ll know that by default it uses ephemeral ports, which means we cannot assume that the port values will always be the same. But no worries, the plugin sets all this information in a bunch of maven properties. This information will be printed out during the build:

So all we need to do is grab those maven properties and turn them into Java System properties. You can do this by simply adding the following lines to the pom.xml:

Then, your Java app can retrieve the values using System.getProperty():

Let’s Run It!

I know you can’t wait to see all this in action so go ahead and run the following maven command to execute the unit tests:

Now invoke the ‘verify’ phase to execute the Integration Tests as well:

And that concludes this series of blog posts. Hope you find this useful!

Warning: A non-numeric value encountered in /home/guillerm/public_html/wp-content/themes/Builder-Cohen/lib/builder-core/lib/layout-engine/modules/class-layout-module.php on line 499