[ 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

Reply via email to