directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [ApacheDS] Separating base unittest classes (Was: Re: svn commit: r307398)
Date Wed, 12 Oct 2005 01:04:23 GMT
Trustin Lee wrote:

> The essential problem in our project is that our tests are not unit 
> tests.  If we're doing unit tests, we don't need to start up the whole 
> ApacheDS everytime we test each classes.  But we're doing so by some 
> reason and the tests takes too much time.  Ideally we should change 
> all of them to unit tests strictly speaking.

You're right these are more *integration* tests and not simple unit 
tests.  Again correctness is not always the most sensible approach in 
our present not so perfect situation :).

It's very hard to unit test these interceptors properly though because 
many presume access to the core.  I see how you performed unit tests on 
the ACI code but I think this was a special case.  Without a harness you 
cannot really test an interceptor.

So what you're suggesting is we move these tests to an apacheds test 
project?  Hmmm ... That would mean we don't have to create the extra 
maven projects since there would be no dep in core and in main for these 
abstract testcases.  I like the sound of this, but it raises some 
concerns for me. I kind of like the fact that nothing deploys unless 
those tests pass even though it takes a long time for them to run.

What else do you think we can do to make sure we protect ourselves?  
Because if we move these "integration" tests into a separate subproject 
it opens the door to the deployment of code in core and main that might 
not work.  The fact that it compiles and simple unit tests run does not 
mean the server will run.  Furthermore if we move the tests, we're going 
to have a lag before the proper unit tests are written.  Who's going to 
retrofit unit tests to all the methods.  No one is my guess.  Right now 
with these integration tests we at least have some kind of coverage to 
keep us from shooting ourselves in the foot.


I should not be advertising this hehe but if test execution times are an 
issue you could always bypass them on builds instead of deploys with 
this option to maven:


Question is: does the fact that someone can do this to deploy artifacts 
to the remote repository make keeping these integration tests in core 
and main moot?  Probably so.  If we do remove these tests then we're 
going to need some serious protocol for managing uploads just to make 
sure these tests run and pass.


View raw message