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
