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 1

If you have ever used the OpenDJ Java SDK to connect to and OpenDJ Directory Server from your application chances are that you’ve asked yourself the following question: how the hell do I test this?

Yes, you can mock most external objects and even spin up an external OpenDJ server for your integration tests, but you wonder if there is  a cleaner and more portable approach.

In this post I will talk about using an In-memory Backend that will greatly simplify your unit test cases while letting you increase your test coverage. I am currently experimenting with OpenDJ Docker images for integration testing and I plan to publish my approach in a future post.

Let’s say you have implemented a Data Access Object (DAO) that uses the OpenDJ SDK to interact with objects stored in an LDAP server. The SDK reduces most of the boilerplate of dealing with connections, entries, etc…an that’s great but writing unit tests for your DAO classes can be a painful task.

Fortunately, the SDK lets you instantiate a special type of Connection Factory that instead of trying to connect to an external Directory Server will connect locally to a backend that resides in memory. You can think of this as a lightweight LDAP server running in memory.

This is how you would typically create a standard LDAP connection factory:

And this is how you can create an In-memory Connection factory:

The ConnectionFactory interface provides a nice level of abstraction so that the classes using these connections (i.e. your DAO classes) won’t care whether the connections are “real” (TCP connections) or “fake” (routed to a memory backend).

I’ve put together a simple end-to-end test to illustrate how easy it is:

Notice how in this example I decided to initialize the MemoryBackend with some entries.

You could use the factory pattern or a dependency injection framework such as Spring IoC or Google Guice to include this approach in your testing strategy with minimum impact to your runtime code.

Finally, I would like to mention that even though you can use a Memory Backend to test most of your code it lacks certain features such as Schema checking so your units tests should always be accompanied by solid integration test cases as well. More about integration testing in the next post.

Happy testing!


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