Java Reference
In-Depth Information
in chapter 5 we strongly discouraged using
Require-Bundle
. We're making an excep-
tion here because it's such a handy provisioning shortcut, and it's only test code. We
won't tell, if you don't!)
Tycho will automatically provision any dependencies of your required bundles, so
you won't need to include your entire runtime platform. But you may find the list is
long enough that it's a good idea to make one shared
test.dependencies
bundle
whose only function is to require your test platform. All your other test bundles can
require the
test.dependencies
bundle.
Your test bundles will almost certainly have a dependency on
JU
nit, so you'll need
to add in one of the main Eclipse p2 repositories to your pom so that Tycho can provi-
sion the
JU
nit bundle:
<repository>
<id>eclipse-helios</id>
<layout>p2</layout>
<url>http://download.eclipse.org/releases/helios</url>
</repository>
As with Pax Exam, you may find it takes you a few tries to get the Tycho runtime plat-
form right. Until you've got a reliable platform definition, you may spend more time
debugging platform issues than legitimate failures. Don't be deterred—having a set of
solid tests will pay back the effort many times over, we promise!
8.3.4
Rolling your own test framework
So far, the
OSG
i testing tools we've discussed have all provided some way of integrating
a unit test framework, like
JU
nit, into an
OSG
i runtime. To do this they've required
you to do some fairly elaborate definition and configuration of this runtime, either in
test code (Pax Exam) or in Maven scripts and manifest files (Tycho). Sometimes the
benefits of running
JU
nit inside an
OSG
i framework don't justify the complexity of get-
ting everything set up to achieve this.
Instead of using a specialized
OSG
i testing framework, some developers rely on
much more low-tech or hand-rolled solutions. A bundle running inside an
OSG
i
framework can't interact with a
JU
nit runner without help, but this doesn't mean it
can't interact with the outside world. It can provide a bundle activator or eager Blue-
print bean to write out files, or it can expose a servlet and write status to a web page.
Your test code can find the file or hit the servlet and parse the output to work out if
everything is behaving as expected. It can even use a series of
JU
nit tests that hit differ-
ent servlets or read different log files, so that you can take advantage of all your exist-
ing
JU
nit reporting infrastructure.
This method of testing
OSG
i applications always feels a little inelegant to us, but it
can work well as a pragmatic test solution. Separating out the launching of the frame-
work from the test code makes it much easier to align the framework with your pro-
duction system. You can use your production system as is, to host the test bundles. It's
also much easier to debug configuration problems if the framework doesn't start as
expected. Both authors have witnessed the sorry spectacle of confused Pax Exam users
