directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <>
Subject [jira] Commented: (DIREVE-225) Protocol Testsuite
Date Sun, 14 Aug 2005 23:47:54 GMT
    [ ] 

Alex Karasulu commented on DIREVE-225:

This is excellent Stefan.  I will prepare a subproject specifically for you to continue your
development there. And yes behavoir with respect to other servers is very important to us
so the more servers you have for developing this test suite the better.


> Protocol Testsuite
> ------------------
>          Key: DIREVE-225
>          URL:
>      Project: Directory Server
>         Type: Test
>     Reporter: Stefan Zoerner
>     Assignee: Alex Karasulu
>     Priority: Minor
>  Attachments: Protocol
> 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