Using ApacheDS for unit tests

The idea is to use ADS as an embedded server for Ldap junit tests. We will build an environment in which it will be convenient to test Ldap applications.

We also want to avoid launching the server for every test, as it's an expensive operation. We have built ApacheDS so that you can start a server, inject some data, launch a test, then revert the data and go on to another test. At the end of the tests, the server is stopped.

First steps

We have two choices : either we launch the server totally embedded, without having to communicate with it using the Ldap Protocol, or we want to use the server as a remote server, with Ldap protocol in the middle (it can be useful if one want to test specific applications). In both cases, the server is started and stopped by the unit test.

We will simply launch only one server (if one want to test referrals, it might be necessary to initialize 2 or more servers)

We have to define a layout for the files and directory we will use in this tutorial. Let's use the maven layout :

Creating a blank test

So let's define the framework we need for a simple unit test, using a server which will be invoked through socket (the first free port above 1023 will be used). This first test will do a search operation on a server.

In order to have this test running, you will need to declare some libraries. The best solution is clearly to define a pom.xml file for that purpose. Here it is :

Is that it ? Pretty much. All you have to do now is to run the test, using a Java 5 JVM and Maven 2.0.9 :

You have written your very first test using the test framework provided in ADS 1.5.5 !

Here are the test files :
SearchTests.java
pom.xml

Test description

Ok, we have a running test, but when it comes to write your own, you need a bit more information. Let's try to explain the different parts of this test.

Annotations

The first interesting part is the annotations we are using. As we said, the server is launched automatically, and we are using the ChangeLog mechanism to restore the base in a pristine state between each test. This is done with annotations.

Server startup

As you can see in the test, there is no place where you tell the server to be started. This is done by the FrameworkRunner. When the tests are all done, the server is also automatically shutdown, and all the created files are removed.

The initialization will update a static ldapServer instance which is declared in the inherited AbstractLdapTestUnit class.

You just have to focus on writing your own tests !

Writing your own test using JNDI

All the LDAP operation are supported, you just have to use the JNDI API to write your tests. The only difference is the way you get a context : you have to use one of those methods :

That's it ! Everything else is just pure JNDI

Writing your own tests using the Netscape API

If you don't like JNDI, or prefer to use the Netscape API (LdapSdk-4.1), you have two major differences :

• first you have to add this API jar into the dependencies in the pom.xml file
• second you will use the getWiredConnection() method instead of the getWiredContext().

The API is :

Both methods are similar to the getWiredContext which has been described before, except that they return a LdapConnection instance.

Creating our own partition

At the moment, we have created a server which is not totally empty : one partition is created by default, the system partition. We won't use it for our tests, so we will need to create our own partition to play with. Let's call it 'o=sevenseas' (o stands for organization)

The setUp() method will be completed with all the needed instruction to create a new partition

Ok, now the partition sevenseas should be created. How can we be sure of that ? let's write a test to replace the emptytest() method :

The test should succeed. Is that all ? Well, almost. As you can see, a working space has been created ( "server-work", at the end of the setup). Do we have to take care of this working space? No. It has been cleaned by the super class !

So everything is fine, the partition is up and running, you are ready to add more tests.

One line in the logs is interesting :

The setup has tried to load an LDIF file to inject some data into the partition, but as we didn't specify any Ldif file to be loaded, nothing has been done. let's add some data !

Adding some data into the partition

The AbstractServerTest class provide a method called importLdif( InputStream in ). It allows you to inject some entries into the newly created partition. How d we use it?

First, we need to have a valid LDIF file containing your entries. We will create two branches in our sevenseas organization :

• one for groups
• one for people

Here is the ldif file we will create :

Save it as a text file into a directory where we will be able to read it directly. But where?

We have created the test into a directory src/test/java/org/apache/directory/demo. This is the maven way to organized the sources, as seen before. Let's create another directory for the resources : src/test/resources/org/apache/directory/demo. Tis is the place where we will save the ldif file.

Now, to let the server know about the ldif file, just add this line after the call to the setup() method :

The getResourceAsStream call will automatically read the file from the resources directory, based on the current class package.

How can we be sure that the data has been imported ? Let's do a search request !

Cleanup the code

Before that, let's do some cleanup. The context creation is something we will have to do in each test. We should create a common method called every time to avoid duplicating this code. Let's create this method :

This method is added into the body of the test class. This method is very simple and quite straightforward : we just create an initial context pointing to the requested partition, and return a directory context on this partition. It takes a parameter, the partition name.

Let's modify the test partition method :

We just replaced the first lines by a call to the newly created createContext() method.

If you launch the unit test, it should still be ok.

Searching for entries

This is really simple. What we will do is to search for the imported entries. Let's go directly to the code. We will add a new unit test

Here, we are looking for all the entries starting at the top level of the partition, within the level. We should only get two entries.

It's not enough : the searchDNs() method does not exist. It is a private method we have created to avoid duplicating some code all over the unit tests. Here is its code :

As for the test partiton, we call the createContext() method, then we just do some JNDI magic :

• creating a SearchControl,
• setting the scope,
• calling the serach
• and gathering the returned DN if any

If the test is successful, you get the imported DNs !

Adding your own schema

Ok, let's go deeper into the server configuration. Working with default schema is fine, but some point, you may want to use your own ObjectClasses and AttributeTypes. let's assume you have created them, and that you have been throw the process of generating the class files for it (this process is described in Custom Schema) into a new package (org.apache.directory.demo.schema) where all the generated files will be put.

You will just have to add those lines at the end of the setUp() method (just before the call to the super() method) :

If we launch the test, nothing special will happen, except that the test will succeed. That's not very impressive...

Conclusion

Ok, this tutorial was a short one, but you get everything you need to play with Apache Directory Server as a Unit Test Engine for your Ldap application. Just create your own partition, define your schema, import your ldif file, and add all the tests you need. it's as simple as explained

If you have any problem, just feel free to post a mail to users@directory.apache.org, we will be there to help !

Resources

• Embedding ApacheDS - Conference Materials