Hi Guys,
It sounds like you're well on your way already, so feel free to
ignore what's below :-).
The JXplorer project has a simple test suite based on LDIF
change files. It was written to test the functionality of JX, but of
course it also checks the server at the same time. It is a command
line tool that runs through an arbitrary LDIF change file, and
reports back on how it went. It's used to test the standard copy/
delete/add/modify operations, as well as some nasty stuff to do with
multi valued RDNs, binary attribute values and so forth.
It used to use junit, but we stopped using it because we wanted
to be able to run the JX client side tests stand alone, and these
were (for us) 'system tests'. But it could be fitted back into the
junit mold if we wanted - the trick though is that because it uses an
LDIF file rather than a series of JUnit like test methods, there
might need to be some adjustment.
Anyway, even though it shouldn't be, it keeps sneaking into the
standard JXplorer release, so it can in fact be used immediately with
the current 3.2b2 version of JX - go to the /jars directory, and type
>java -cp jxplorer.jar com.ca.commons.jndi.TestJNDIOps -h and it
will print out its usage parameters 'n stuff. I suspect we'd need to
work on it a bit for the use of ApacheDS, but it's a current, working
implementation similar to that used in the overnight build tests at CA.
It may be that there is room for multiple test tools to run in
an automated fashion - it sounds like what people are talking about
below is much more low level; this tool basically imitates a java
jndi client. It is convenient, since it just uses the standard LDIF
change file format and new tests simply involve adding a new snippet
of LDIF, but other tools may be able to more rigourously exercise the
full functionality of the Apache DS.
cheers,
Chris
P.S. The code is licensed under the 'CA open source license', which
is equivalent to Apache (and which I can't change :-( ); since we
wouldn't be distributing the code though there is no reason why we
can't use it for testing without formal acknowledgement...
P.P.S. The source files are in the JX cvs tree (com/ca/commons/jndi/
TestJNDIOps) but not (yet) in the standard source distribution
packages...
On 19/08/2005, at 6:41 AM, Stefan Zoerner wrote:
Emmanuel Lecharny wrote:
On Thu, 2005-08-18 at 19:13 +0200, Stefan Zoerner wrote:
Hi all,
Hi Stefan!
Thanks for your reply, Emmanuel!
<snip/>
For a start JUnit and JNDI are used, there is no dependency on
code which is provided by the Apache Directory Project (we do
black box tests). While JUnit is beyond dispute, JNDI is not.
JNDI is very commonly used. So it doesn't arm to use it. Better
have a
way to test ApacheDS than arguing about the best tool to do it :)
<snip/>
You are right, I will rework this passage.
<snip/>
I'm still on my way to create a simple test framework based on XML
files. I just lack of time to finalize it, but I may found it
soon! The
idea is to use the asn1-codec to send request and to test expected
responses. The XML file will store the data and the expected
response.
The tool will just launch those tests and give back a result. It
will be
easy to add a new test, as the structure will be controlled by a XSD
(the XSD already exists).
Another way to store tests could also to use the proxy to capture
PDUs
and replay them. you will then be able to create scenarios and tests
them against different kind of LDAP server (the proxy already exists,
and have been tested against ApacheDS and IDS, with LdapBrowser and
JXplorer - snapshot attached). Of course, I need to improve this
proxy
to dump XML structures to disk, but that's not very complicated.
Except
that I have to find time to do it ;)
Especially the proxy seems to be a very useful and interesting
thing! Even in other scenarios. It may help me to ensure that JNDI
really sends the operations I want it to (currently I run the tests
against Sun DS and look in its logs ...). And it would definitly be
helpful in tutorials to teach people LDAP/JNDI (I give an
introduction to LDAP for Java developers in November in Munich on a
conference, for example). Are the sources for the proxy GUI already
in the Apache DS svn? It may also be interesting in integration
tasks, e.g. for research if someone fails to integrate an LDAP
server in a middleware, because the latter is poorly documentated.
Have you ever thought about offering it in the client section of
the Apache Directory Project?
Jmeter could also be an opton. I've done some very simply tests once
upon a time using it, just to check how ApacheDS was doing against
OpenLdap. The answer was : almost as fast. But it was over
simplistic.
It's very interesting to improve those tests to do some benchmarks !
Yes, I thought about JMeter as well. Especially because it gives us
remote JMeter engines on different machines for heavy load tests.
Nice task for my little test center here (I collect old Sun
workstations ...). But first I would like to complete the test
cases for the little test suite. JNDI biggest advantage will be
that Alex can integrate theme easily in the sercer test suite (at
least If we find a way to do this wothout copying to much code). He
may use your internal JNDI provider, while the testsuite run the
original LDAP provider included in the J2SE.
so, we have a lot of things to do, and we are very few... Welcome
Stefan !
Thank you to welcome me aboard. The more users we have, the more
helping hands will appear. This is why I am so interested in
improving end user experience (and this starts with standard
compliance and includes documentation, which I am also interested
to contribute). If a user fails to use the server (e.g. because his/
her clients refuse to work correctly with it), s/he will choose
another ... .
Bye, Stefan
