Testing applications - OSGi in Action - page 234

The module property refers to the org.apache.commons.pool package, which you
also use as the symbolic name of the main bundle. This is all you need to declare
your test bundle as a fragment of the main library bundle. With this change in place,
you can rebuild and repeat the test. You should see JU nit run through the complete
Commons Pool test suite, which takes around two minutes:

$ ant clean test.osgi
...
[junit.osgi] ....................................
[junit.osgi] ....................................
[junit.osgi] ....................................
[junit.osgi] ....................................
[junit.osgi] ....................................
[junit.osgi] ....................................
[junit.osgi] Time: 118.127
[junit.osgi]
[junit.osgi] OK (242 tests)
You're now running all your tests inside the combined library bundle (the intra-
bundle option from figure 7.1) because your test fragment contains both internal and
public-facing tests. You could go one step further and use a plain bundle for public
tests and a fragment for internal tests, but you'd need some way to give JU nit access to
your internal tests. At the moment the public org.apache.commons.pool.TestAll
class loads internal tests from inside the same fragment, but this won't work when you
separate them. You don't want to export any internal packages from the fragment
because that would also expose internals from the main bundle, potentially affecting
the test results.
The least disruptive solution is to keep a single public test class in the fragment that
can be used to load the internal tests. You can move the remaining public-facing tests
to a new package that doesn't conflict with the library API (such as .test ) and deploy
them in a separate bundle. The result is
a combination of both inter-bundle and
intra-bundle testing. Figure 7.3 shows
an example of such a structure for test
ing Commons Pool.
You can also run the test example
outside of the container by invoking
JU nit with the various bundles on the
standard Java class path. In this case,
you don't need to start the OSG i
framework. To try this, use the test
build target instead of test.osgi .
You should see the same results as be-
fore:

OSGi

org.apache.commons.pool.test

JUnit

org.apache.commons.pool
org.apache.commons.pool.impl
(test fragment)

Figure 7.3 Recommended test structure for OSGi
bundle tests

$ ant clean test
...
[junit] ........................................
[junit] .........................................