Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Rich Client Platform (RCP) » jUnit Plugin Test Best Practices
icon5.gif  jUnit Plugin Test Best Practices [message #546438] Mon, 12 July 2010 19:00 Go to next message
Christian Kesselheim is currently offline Christian KesselheimFriend
Messages: 59
Registered: June 2010
Hello everybody,

I'm working on a sort of large-ish RCP project employing a number of other Eclipse/OSGi technologies such as Riena, EclipseLink, Spring DM and several standard PAX/Equinox services.

Since we organize our work along the lines of TDD, our code base features quite a number of jUnit tests (both standard and OSGI-aware), all partitioned into >20 bundle fragments (give or take a few).

So far, each of these 20 bundle fragments also includes its own (shared) launch configuration for quickly starting all tests that this particular bundle contains (both from within the IDE and the Buckminster-driven headless build).

So far, so good. Unfortunately, we're not yet 100% happy with the solution we've chosen:

  • Keeping these >20 launch configurations up-to-date is pretty hard work. Each time someone adds/drops a bundle dependency deep down all >20 launch configurations will need to be (manually) updated. We've initially considered using feature-based launch configurations to ease the pain, but since some of our dependencies (EclipseLink, Pax Logging, etc.) need to have their start-level hard-wired, this doesn't seem to be an option.
  • Since we build cross-platform (MacOSX, Linux, Windows) but still use bundles (not features) to define the launch configurations of our tests, we sometimes struggle with dependencies to native fragments (e.g. SWT Cocoa vs. SWT Win32) that ought to be resolved differently depending on what platform you're currently working on.
  • Also, we've so far not found a way to start all jUnit Plug-In Tests at once from within a single launch configuration. All tips and tricks on how to create composite jUnit test suites for your application seem to be based on the idea that you're using standard OSGi bundles (not fragments) to package your tests (which we are not).
  • The OSGi testing support from Spring DM/Gemini Blueprint (that is, the ability to provision, start and orchestrate an embedded OSGi container from a standard jUnit test class) also disqualified since it relies on your bundle dependencies to be available in packaged form at the time the test is started (which isn't necessarily the case if you're launching the whole thing from within the IDE).

With all that and more, we wonder if there's really no one out there with similar requirements who could lend us a tip or two on how to best work with OSGi-aware unit tests and their respective Eclipse launch configurations.

Thanks in advance Smile,


Re: jUnit Plugin Test Best Practices [message #546442 is a reply to message #546438] Mon, 12 July 2010 19:12 Go to previous messageGo to next message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

I can't speak for best practice, but in Platform UI we chose one or two
main test suite per bundle, we saved the launch config of those major
suites in our project as well, and our test suites all run with "all
workspace and target platform plugins".

That way your launches will always be available and you won't have to
guess which platform you're on. We had to take extra steps for certain
testing scenarios, like using the BundleContext/PackageAdmin to install
bundles for dynamic plugin testing.

The eclipse automated test process lays down an eclipse SDK, and then
uses the director to install the current test plugin + test harness.
Then it runs the major test suites via ant.


Paul Webster .platform.doc.isv/guide/workbench.htm

Re: jUnit Plugin Test Best Practices [message #546448 is a reply to message #546442] Mon, 12 July 2010 19:35 Go to previous message
Christian Kesselheim is currently offline Christian KesselheimFriend
Messages: 59
Registered: June 2010
I see. In your opinion, how best to handle the start-level problem, then? Meddle with config.ini or use PackageAdmin, instead?

EclipseLink is an especially nasty citizen in this respect, as it will just spit out some obscure error message and refuse to work if you leave start levels/autostart settings at their initial defaults Confused.
Previous Topic:EFS - CMIS based implementation
Next Topic:plugin/manifest editor question
Goto Forum:

Current Time: Thu Feb 09 06:37:29 GMT 2023

Powered by FUDForum. Page generated in 0.02140 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top