directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject [ApacheDS] Separating base unittest classes (Was: Re: svn commit: r307398)
Date Tue, 11 Oct 2005 19:39:52 GMT
Emmanuel Lecharny wrote:

>>>Ooops. May be a little convo on IRC could help a lot avoiding the code
>>>breaking I induced...
>>> 
>>>
>>>      
>>>
>>Let's keep this on the list.  
>>    
>>
>
>+1
>
>  
>
>>Also we *MUST* always make sure we summarize our conclusions on IRC.
>>    
>>
>
>+1 to this kind of wish
>
>  
>
>>Please don't take this Emmanuel this is more a reminder to myself :-) as 
>>well.  We neeed to watch how much info is lost on IRC now that our IRC 
>>channel's are not being logged anymore.
>>    
>>
>
>We must find a way to log those infos, and how to publish them.
>
>
>Back to the pb, what about a test-setup subproject in apacheds project?
>  
>
What do we have today?
========================

Right now apacheds has the following subprojects:

shared
core
main
plugin

Let's try to understand some of the dependencies:

main deps core
main deps shared
core deps plugin
core deps shared
plugin deps shared

The the unit testing "framework" (if you could call it that) for 
apacheds' *core* is just composed of three classes.  We're talking about 
AbstractTestCase, AbstractAdminTestCase and AbstractNonAdminTestCase.  
These test cases do not fire up the protocol providers for apacheds ... 
just the core.  This means you cannot do over the wire LDAP tests using 
the SUN JNDI Provider or with JLDAP with these TestCase base classes.  
This code just depends on the core and on shared.

In the *main* project resides another testcase base class called 
AbstractServerTest which turns on the protocols in addition to firing up 
the core.  This code depends on the main, core and shared.


Why should we separate unit test base classes?
==============================================

Now let's ask ourselves why we need to separate this stuff out from core 
and main.  I think its because we don't want these necessarily shipping 
with the core or the main since users may not be interested in unit 
testing and hence do not require those classes or the jars they depend 
on.  It thus makes sense, why, you Emmanuel, did not want these files in 
the src/main/java directory but in the src/test directory.  So 
separating them out of the core and main is a good idea.  How this is 
done or if it's worth doing is another story.

The How?
==========

Let's start first by just considering the core.  It has the 3 abstract 
test cases which must be removed however these test cases depend on core 
classes.  Core in turn depends on the test cases to drive its tests.  
This imposes a cyclic dependency.  So we cannot just separate the test 
base classes from the core.  We need to create some shared project that 
both the core and the core-unit tests depend on to break the cycle.  We 
have the same situation for the main.  In the end if we were to do this 
right then we need to create 4 new maven child projects for apacheds:

core-shared
core-unit
main-shared
main-unit

Is it worth it?
==============

IMHO it is not worth creating 4 new maven projects to get 3 classes out 
of the way.  This is the conclusion I came to 6 months ago when I had 
the idea of making this separation. 

What do I think now? Well let's not mess with this:

(1) the entropy incurred for absolute correctness is too much
(2) the unit tests are nice to have in the jar: they're just there if 
you need em
(3) the junit jar is not required as a dependency at runtime unless you 
use the base unit tests

So in the end, I actually think it becomes more convenient to leave the 
base test cases as-is in their respective src/main/java directories in 
core and main respectively.  Let's not bother with 4 new maven 
projects.  WDYT?

Alex


Mime
View raw message