Protocol Testsuite
------------------
Key: DIREVE-225
URL: http://issues.apache.org/jira/browse/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 jndi.properties.
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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
