[ http://issues.apache.org/jira/browse/DIREVE-225?page=comments#action_12318840 ]
Alex Karasulu commented on DIREVE-225: -------------------------------------- Stefan i just created a new project project at the top level of directory for your testsuite. It really belongs in its own category since it will be independent of apacheds although testing it. Now what we need you to do is take care of this with maven so it can be built easily like other projects and has some good documentation. Thanks for the contrib. > 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
