The gold standard for OSG i testing tools is a tool called Pax Exam. Pax Exam is part of
a suite of OSG i-related tools developed by the OPS4J open source community. In con-
trast to other open source communities like the Apache and Eclipse Foundations,
OPS4J has an interestingly flat structure that emphasizes open participation as well as
open consumption. There's no notion of a committer , no barrier to committing source
changes, and little internal hierarchy.
Pax Exam builds on other tools developed by OPS4J , such as Pax Runner, to pro-
vide a sophisticated framework for launching JU nit—or Test NG —tests inside an OSG i
framework and collecting the results. Under the covers, the Pax Exam framework
wraps test classes into a bundle (using bnd to generate the manifest), and then auto-
matically exposes the tests as OSG i services. Pax Exam then invokes each test in turn
and records the results.
HOW CLEAN IS YOUR FRAMEWORK?
By default, Pax Exam will start a fresh framework for each test method, which means Pax
Exam tests may run slowly if you've got a lot of them. In recent versions, you can speed
things up—at the risk of interesting side effects—by specifying an @ExamReactor-
Strategy annotation. You can also choose whether Pax Exam launches the OSG i frame-
works inside the main JVM or forks a new JVM for each framework, and runs tests by RMI
(Remote Method Invocation). Not spawning a new JVM makes things far faster, and it
also means you can debug your tests without having to attach remote debuggers. But
many of the more useful options for configuring frameworks are only supported for the
remote framework case.
Which container to use is determined by which container you list in your Maven
dependency. To use the quicker nonforking container, add the following dependency:
To use the more powerful, but slower, Pax Runner-based container, specify the
ENABLING TESTS FOR PAX EXAM
A JU nit test intended for Pax Exam has a few key differences from one that runs stand-
alone. Running your test code in an entirely different JVM from the one used to
launch the test, with RMI and all sorts of network communication going on in the
Search WWH ::