Testing applications - OSGi in Action - page 233

scan bundles for tests and feed the class instances to JU nit, instead of relying on the
standard test runner. We'll look at a tool that does this in section 7.3. Let's try the
other approach here: bundling JU nit.
You can use the bndwrap Ant task from the bnd tool ( http://aqute.biz/Code/Bnd )
to quickly wrap the JAR file. The bndwrap task analyzes the JAR and creates a bundle that
exports all packages contained inside it. It also adds optional imports for any packages
that are needed but not contained in the JAR file. Unfortunately, this import list doesn't
contain your test packages, because JU nit doesn't know about them yet. To avoid having
to explicitly list your test packages at build time, you can instead use DynamicImport-
Package: * (discussed in section 5.2.2). This dynamic import means JU nit will be able
to see any future test class, as long as some bundle exports them.
Also add the following Main-Class header:

Main-Class: junit.textui.TestRunner
This tells your example launcher to start the JU nit test
runner after deploying all the bundles. The TestRunner
class expects to receive the name of the primary test
class, so add org.apache.commons.pool.TestAll to the
OSG i launcher command line in build.xml. (Your
launcher will automatically pass any arguments after the
initial bundle directory setting on to the Main-Class .)
Figure 7.2 shows the test deployment, which is the
inter-bundle option from figure 7.1.
Let's try it for real:

OSGi

Commons Pool
tests

JUnit

Commons Pool

Figure 7.2 Testing Commons
Pool inside an OSGi framework

$ cd chapter07/migration-example
$ ant clean test.osgi
...
[junit.osgi] Class not found "org.apache.commons.pool.TestAll"
[junit.osgi] Java Result: 1
Hmm...the JU nit bundle couldn't see the TestAll class even though the test bundle
clearly exports it. If you look closely at the package involved and cast your mind back to
the visibility discussion from section 2.5.3, you should understand why. This is the same
package that's exported by the main Commons Pool bundle! Remember that packages
can't be split across bundles unless you use bundle dependencies (section 5.3), and
you're using package dependencies. You could use Require-Bundle to merge the pack-
ages together and re-export them (see section 5.3.1 for more about re-exporting pack-
ages), but you'd then need to use mandatory attributes to make sure JU nit and other
related test bundles were correctly wired to the merged package. This would lead to a
fragile test structure and cause problems with package-private members (to find out
why, see the discussion near the start of section 5.4.1).
A better solution is to use fragments (section 5.4) to augment the original bundle
with the extra test classes. To do this, you need to add one line to test/build.properties:

Fragment-Host: ${module}