Testing applications - OSGi in Action - page 232

exposed from the external class path, the tests will effectively be running outside of the
container. Does this mean you should bundle tests along with the application code? It
depends on how you expect the code to be used in OSG i. Internal classes can only be
tested from inside the same bundle, but public-facing code can and should be tested
from another bundle to mimic real-world conditions. Testing code inside the same bun-
dle typically means the caller and callee share the same class loader, but many OSG i-
related issues only appear when different class loaders are involved. So, wherever pos-
sible, test from another bundle.
Figure 7.1 summarizes the four
possible test-deployment options:

Boot class path System bundle export

Tests Tests

Boot class path

■

OSGi

OSGi

System bundle export

■

Intra-bundle

■

Inter-bundle

■

We'll concentrate on the last two op-
tions (intra-bundle and inter-bundle
tests) because it's much more realistic
to have the test code running inside
the container along with the code
being tested. Bundle testing means
deploying tests in bundles just like
any other piece of code, but how
much effort is involved in getting tests
up and running in an OSG i framework? Let's find out right now by converting an exist-
ing open source library and its test suite into separate bundles.

Intra-bundle Inter-bundle

OSGi

OSGi

Tests Tests

Figure 7.1 Test deployment options

7.1.2 Bundling tests

The Apache Commons Pool project ( http://commons.apache.org/pool/ ) provides a
small library for managing object pools. You'll use the source distribution for Com-
mons Pool 1.5.3, which contains the code for both the library and its test suite:

chapter07/migration-example/commons-pool-1.5.3-src.zip
Begin the example by splitting the Commons Pool library and tests into two bundles.
The main subproject extracts the library source, compiles it, and creates a simple bun-
dle that exports the main package, but hides the implementation (.impl) package.
The test subproject does exactly the same thing for the test source, but it appends
-test to the bundle symbolic name to make sure the bundles are unique.
The Commons Pool tests are JU nit tests, so you also need access to the JU nit
library. Should it be deployed as a bundle or placed on the external class path? Expos-
ing the packages from the external class path means you don't have to turn JU nit into
a bundle, but it also means JU nit can't see test classes unless they're on the same class
path or explicitly passed in via a method call. You'd have to write your own code to