Re: [equinox-dev] Good support for PDE in build systems anyone?

[BJ Hargrave <hargrave@xxxxxxxxxx>]

Another idea is to put the test in a fragment of the bundle being tested. 
The fragment can even extend the packages in the bundle to test package 
private functions...

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@xxxxxxxxxx
Office: +1 407 849 9117 Mobile: +1 386 848 3788



Grahame Grieve <grahame@xxxxxxxxxxxxxx> 
Sent by: equinox-dev-bounces@xxxxxxxxxxx
2006-06-05 04:48 PM
Please respond to
grahame@xxxxxxxxxxxxxxx; Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc

Subject
Re: [equinox-dev] Good support for PDE in build systems anyone?






current practice is to have unit tests in a separae
package because of package dependencies. All fine,
but you do end up publishing stuff solely to test it.
it'd be nice - at some time - to be able to 
publish packages for testing purposes only, though
I'm not sure whether that could be anything more than
a nominal differentiation. even then it would be useful.

Grahame


Alex Blewitt wrote:
> On 05/06/06, Andrew Niefer <aniefer@xxxxxxxxxx> wrote:
>>
>> Niclas Hedhman wrote on 06/04/2006 11:52:33 PM:
>>
>>  > Also, how does PDE know what classpath to use for "unit testing" vs
>> normal
>>  > runs??
>>
>> Under Eclipse, the unit testing is generally under a separate 
>> project.  So a
>> bundle A.test will depend on bundle A and there is no such thing as a
>> "testing run" as far as A is concerned.  A is built the same for a 
>> testing
>> run as it is for a normal run.
> 
> It's possible to have a bundle that incorporates some test code, but
> does not export it when doing a 'production' build. Quite a lot of the
> time, it's easier to associate test code with source code in the same
> bundle/module (or project, in Maven terms) instead of having an
> uber-test bundle that tests everything in a feature (e.g. the way
> Eclipse is tested). The bundle can be built with or without test code
> incorporated (or attached as a fragment).
> 
> Another way is to have two separate bundles; and the testing bundle
> can depend on the production bundle. However, that often doesn't have
> access to certain internals that you may want to test.
> 
> I wrote a bundle tester that would scan a bundle for all the XxxTest
> classes, and allowed out-of-container testing on those tests that
> didn't need an Eclipse/OSGi framework up and running, but ran some
> in-container tests that did need an Eclipse/OSGi framework. The
> advantage was that a lot of the small unit tests were just exercising
> Java functionality, rather than utilising Eclipse APIs, and therefore
> many tests could be run without having to bounce an OSGi environment
> all the time.
> 
> I wrote up my example code on
> http://alblue.blogspot.com/2006/03/javaeclipse-running-all-tests-in.html
> as well as making it availbale in the RCPApps stuff I demo'd at
> EclipseCon.
> 
> Alex.
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> 

-- 
Grahame Grieve
CTO, Jiva Medical       Software Integration Tools
CTO, Kestral Computing  Healthcare Applications 
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev