Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Re: Re: [equinox-dev] Package access across plug-ins... 
On 22/10/06, Kirby Bohling <computerslicer23@xxxxxxxxxxx> wrote:

Alex,

   Essentially, I have four constraints:

1. Unit tests running in Nightly Builds via Eclipse builds in an Eclipse
Application.


Sounds reasonable enough. The article on www.eclipse.org is a good
summary of the stuff, as well as the presentation from EclipseCon2006
which I gave last year. It's available via
http://www.rcpapps.org/EclipseCon2006/ if you need it.


2. Not bloating shipping applications (no test code and JUnit libraries
shipping with plug-ins).


Obviously, a good idea. One advantage of testing (per fragment) is
that you have a separation between deployable code and testing code.
Of course, you end up with double the number of buildable bits if you
do this.

Another approach is to have the test in a separate source folder (e.g.
src/main/java and src/test/java) inside the same bundle, and have both
on the bundle classpath. Then, during the build process, strip out the
tests e.g. by removing the src/test/java/ from the build.properties.
Or, you can have the test code compile to a separate classpath (e.g.
src..=src/main/java and src.test.jar=src/test/java and then strip out
the src.test.jar).

One downside to this is you end up with a dependency on org.junit (or
similar) in your bundle's classpath. However, you can mark this with
optional so that it's not necessary for the bundle to run, but will
use it.

This second approach is the easiest from a module management (because
there's less of them) and often couples the test code to the prod code
(also a good thing, but that's your #4 concern). However, it makes the
build a bit trickier to do. It would be nice if a PDE project could
contain two bundles; for example, by having separate
META-INF/MANIFEST.MFs in the bin/main and bin/test directories ... but
it's not capable of that right now :-)


3. Not generating more plug-ins or fragments then is necessary.


If you can strip out the test.jar from the builds above, you have no
more. If you go down the fragment route, then you end up with
potentially as many fragments as you have bundles, but it's certainly
the 'clean' way of doing it.


4. Test code near prod code.  (Organizationally, inside the same SVN
module).


Yup, that's always a good goal to have. If you go with one large test
bundle, you don't have this cohesion; if you go with one test fragment
(or one test source folder) per bundle, then you've solved this
problem.


I'll look thru the blog link.  I've got everything mostly done.  The
JUnit interfaces/implementations would be worth porting to.  I've decided to
use fragments for the existing tests.  My current problem is finding a
canonical way to say "Always load this fragment".


Should happen automatically, if you're using the
org.eclipse.update.configurator. If you're going down a route of
specifying every individual bundle in the config.ini, then perhaps a
fragment wouldn't get started, but I'm not sure. It would be
interesting to see why it isn't, but Jeff gave some good advice about
running with eclipse -console -noExit and doing an ss to show you what
the status of the bundles/fragments are.

Alex.

Back to the top