[jira] Closed: (DIRSERVER-501) Protocol Testsuite

["Stefan Zoerner (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/jira/browse/DIRSERVER-501?page=all ]
     
Stefan Zoerner closed DIRSERVER-501:
------------------------------------


The source provided with this issue has been committed long time ago. Therefore I close this one.

> Protocol Testsuite
> ------------------
>
>          Key: DIRSERVER-501
>          URL: http://issues.apache.org/jira/browse/DIRSERVER-501
>      Project: Directory ApacheDS
>         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