[ http://issues.apache.org/jira/browse/DIREVE-225?page=all ]
Stefan Zoerner updated DIREVE-225:
----------------------------------
Attachment: Protocol Tests.zip
As I said, this is just a preview. I will contribute a more complete testsuite
later on, especially after including your feedback and making the bar green
against Active Directory.
> Protocol Testsuite
> ------------------
>
> Key: DIREVE-225
> URL: http://issues.apache.org/jira/browse/DIREVE-225
> Project: Directory Server
> Type: Test
> Reporter: Stefan Zoerner
> Assignee: Alex Karasulu
> Priority: Minor
> Attachments: Protocol Tests.zip
>
> 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
