 jUnit Plugin Test Best Practices [message #546438] |
Mon, 12 July 2010 19:00  |
 Christian Kesselheim
Messages: 59
Registered: June 2010 |
Member |
|
|
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  ,
Chris
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04216 seconds
] 
Search
Help
Register
Login
Home
.