directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Zoerner (JIRA)" <>
Subject [jira] Created: (DIREVE-225) Protocol Testsuite
Date Sun, 14 Aug 2005 20:45:54 GMT
Protocol Testsuite

         Key: DIREVE-225
     Project: Directory Server
        Type: Test
    Reporter: Stefan Zoerner
 Assigned to: Alex Karasulu 
    Priority: Minor

Here is a preview for a simple protocol testsuite. My plan is to create unit tests for all
basic LDAP operations and some other client use cases. Things like schema browsing, Root DSE,
Control support, StartTLS, ... 

The suite acts as a client and will be tested against several LDAP servers. I will only include
tests, which behave the same on all solutions.
Current plans include:

* OpenLDAP
* Sun Java System Directory Server
* Active Directory Application Mode
* Novell eDirectory
* IBM Tivoli Directory Server

At least these are the servers I have in my little lab here.

Later on it may be run against Apache DS as well, e.g. to compare whether the the server acts
comparable to the other solutions.  

This code here is just a start. It includes only some tests for three operations (add, delete,
modify dn). I attached the source code mainly to present the structure I planned and gain
some feedback. There is a lot of work left to do, especially some refactoring.

The tests ran succesfuly against OpenLDAP, Tivoli and Sun. I plan to add Novell and Active
Directory as well in the near future. Currently I have some trouble with schema restrictions
in AD with the modify dn op (person must have cn as RDN, cn is single valued, not very RFC-like
...). I will rework the tests and find a solution here. And my eDirectory needs some configuration
first ...

Before I will continue to add more tests and operation types I would appreciate your feedback
on the following ideas.

I would prefer to have a standalone version (e.g. singe jarfile with JUnit classes included)
which behaves like standard LDAP command line tools. e.g.

ldapoptests -h <hostname> -p <port> -D uid=... -w **** -b "dc=apache"

For now, it is just a testsuite and configuration is via

And it will be necessary to define the requirements to successfully run the tests. Currently,
the tests create a test entry below the base DN, and below this they operate. Via setUp()
it is assured that the test entry exists and is empty before each test, and it is necessary
that the user has write access to it.  Furtheron some assumptions are necessary with respect
to the schema (see AD problems).

Currently JNDI is used for the operations. Because most of your users will use this API, and
no dependencies to other libs are necessary, it seems to be an appropriate selection to start
with. I have created a subpackage *.jndi.*, because later on I can imagine to use an explicit
LDAP API as well. Some things are hard to test with JNDI (e.g. response controls during bind,
abandon operations), a LDAP lib would complete the picture. Maybe it is possible to use the
client libs of your project? A nice addon effect would be to test these classes against several
directory servers ...

It will also be necessary to document the test cases. For a first run I used AspectJ to create
an audit trail with all operations raised against the server for each test as LDIF. The tool
may not be approriate (I read you stopped to us AspectJ), but the form is probably fine, because
LDIF fragments can easily used by other tools.  

Alex suggested to create an own subproject for a test suite of this kind. How about placing
it in the client section? Then there is no other subproject necessary, and if implemented
as a client like outlined above, it would fit as well.  

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message