directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Zoerner <>
Subject Protocol Testsuite: Mission Statement (Proposal)
Date Thu, 18 Aug 2005 17:13:40 GMT
Hi all,

here is my first draft for a Mission statement for the test suite 
subproject, Alex suggested. Any comments/corrections -- please note that 
English is not my first language (and not my second, which is LDIF) --  
are welcome!

Greetings from sunny Hamburg,


Protocol Testsuite: Mission Statement (Draft)

The success of Apache Directory Server (as of any LDAP server) depends 
heavily on interoperability. May it be used as a user repository of an 
arbitrary J2EE application server (or web server, or mail server, or ... 
You name it)? Can you plug it into your favorite mail tool as an address 

Thus the primary aim of this subproject is to provide a test suite which 
is used to ensure that Apache Directory Server behaves like a 08/15 
(i.e. an ordinary, bulk commodity) LDAP client would expect. Therefore 
it concentrates on the functionality which is undisputable among 
different LDAP vendors/providers. We run the test suite against major 
directory solutions (commercial and Open Source), just to be sure that 
we check common sense.

For a start JUnit and JNDI are used, there is no dependency on code 
which is provided by the Apache Directory Project (we do black box 
tests). While JUnit is beyond dispute, JNDI is not. The JNDI framework 
is an abstraction for naming and directory services, and some LDAP 
operations are not straight forward to perform with JNDI (e.g. compare, 
abandon). But the option to create a test suite which does not depend on 
an "explicit" LDAP library (like Netscape SDK) and the fact that a lot 
of the Apache Directory Server users will choose JNDI for integration 
lead us to the decision to start with it.

Later on this subproject may support the main development of the Apache 
Directory Project with tests for topics which are not rock-solid 
standardized (e.g. access control lists). Or performance tests. Or ... . 
But as long as any client may complain about the behavior, we will 
concentrate on basic operations. Client experience is key.

External links, if placed on the site:
Black box testing:
Netscape SDK:

View raw message