|
Home > Archive > Apache Directory Project > October 2007 > Testing with a specific server.xml
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Testing with a specific server.xml
|
|
| Randy Motluck 2007-10-18, 1:11 pm |
| All,
How can make the unit tests and integration tests use my changed server.xml.
I have some alternate backend components that I am trying to write/test.
It does not seem clear to me how the integration tests work. I know how to
run them, just not get them to work with my specifc backend components.
Any help is appreciated.
-Randy Motluck
| |
| Stefan Zoerner 2007-10-18, 7:11 pm |
| Randy Motluck wrote:
> How can make the unit tests and integration tests use my changed
> server.xml. I have some alternate backend components that I am trying
> to write/test.
>
> It does not seem clear to me how the integration tests work. I know how
> to run them, just not get them to work with my specifc backend components.
The integration tests do not use the server.xml configuration (Spring
Framework). The server runs embedded and is configured programatically.
One option would be to add your custom components programatically to the
configuration as well.
Greetings,
Stefan
| |
| Randy Motluck 2007-10-18, 7:11 pm |
| Thanks for the reply.
I think I may look into subclassing those tests and overriding the
dependency setting...to ensure proper functionality on my stuff.
I have not looked yet at the tests while at work, but this evening, while at
home, I will check to see how feasible that is.
Again, thank you.
-Randy Motluck
On 10/18/07, Stefan Zoerner <stefan-EQq9qWhC7IA@public.gmane.org> wrote:
>
> Randy Motluck wrote:
>
> components.
>
> The integration tests do not use the server.xml configuration (Spring
> Framework). The server runs embedded and is configured programatically.
>
> One option would be to add your custom components programatically to the
> configuration as well.
>
> Greetings,
> Stefan
>
>
| |
| David Jencks 2007-10-18, 7:11 pm |
|
On Oct 18, 2007, at 10:39 AM, Randy Motluck wrote:
> All,
>
> How can make the unit tests and integration tests use my changed
> server.xml. I have some alternate backend components that I am
> trying to write/test.
>
> It does not seem clear to me how the integration tests work. I
> know how to run them, just not get them to work with my specifc
> backend components.
>
> Any help is appreciated.
I'm not sure what you are trying to test or how applicable any
existing tests might be to your components. I've just updated my
triplesec copy to work with the bigbang branch and gotten several
integration tests to work with a server.xml. They use the Service
object from integration/apacheds-noarch to start up a server with my
triplesec server.xml.
My triplesec branch is at https://svn.apache.org/repos/asf/directory/
sandbox/djencks/triplesec-jacc2
The base test class is TriplesecIntegration in the integration module
and a typical use of it is TripleSecPolicyIntegrationTest in the jacc
module.
The only thing that can be said for this code is that it works, it
needs enormous amounts of cleanup.
In general I think it would be great if we had more spring based
integration tests. So far there isn't even a test to show whether
the final server will start.
hope this helps
david jencks
>
> -Randy Motluck
| |
| Alex Karasulu 2007-10-18, 7:11 pm |
| There are several neat things we can do to enable reuse of the test code for
different configurations.
The key lies in separating out the tests which test the protocol from those
that test server internals
in these tests may fail under different configurations. To some degree this
is true for most cases
obviously, not configuring the LDAP server will break all protocol tests.
However presuming at a logical
level you have the same relative LDAP configuration just use a different
partition implementation or use
a new handler etc then this code should work. And reuse becomes valuable to
affirm that this is actually
the case.
We tried to separate the protocol testing code to some degree with
server-unit verses core unit.
However with more people forgetting the original intent of the separation I
think it's gotten out of hand.
Regardless test reuse can be achieved if we can decouple the tests from the
configuration: more specifically
how the server is configured and started. Doing so will allow all sorts of
possibilities.
(1) plugging in different component implementations to confirm correct
operation
(2) using a pool of servers that have already been fired up to speed up and
parallelize protocol tests
(3) applying these tests on other servers to see how they behave in various
situations
I think there are more possibilities here besides the 3 I listed.
Alex
|
|
|
|
|