Testing applications - OSGi in Action - page 235

[junit] ....................................
[junit] ....................................
[junit] ....................................
[junit] ....................................
[junit] Time: 117.77
[junit]
[junit] OK (242 tests)
You've seen how easy it is to run tests both inside and outside of a container, but how
do you know if you're testing all possible scenarios and edge cases? Most projects use
coverage to measure test effectiveness, although this doesn't guarantee you have well-
written tests! Given the importance of test coverage, let's continue with the example
and find out how you can record coverage statistics inside an OSG i container.

7.1.3 Covering all the bases

It's always good to know how much of your code is being tested. Like test results,
coverage can vary depending on whether you're testing inside or outside a container.
This makes in-container tests just as important as out-of-container tests when determ-
ining overall test coverage.
We can break the coverage-gathering process into three stages:
1

Instrument the classes

Execute the tests

2

Analyze the results 3

The first and third stages can be done outside of the OSG i container. This leaves you
with the second stage: testing the instrumented classes inside the chosen container.
You already know you can run the original tests in OSG i, so what difference does
instrumentation make? It obviously introduces some sort of package dependency to
the coverage library, but it also introduces a configuration dependency. The instru-
mented code needs to know where to find the coverage database so it can record
results. You can deal with the package dependency in three ways: wrap the coverage
JAR file up as a bundle, export its packages from the system bundle using
org.osgi.framework.system.packages.extra , or expose them from the boot class
path with org.osgi.framework.bootdelegation . When using boot delegation, you
must make sure coverage packages are excluded from the generated Import-Package
in the library bundle or at least made optional. (Not doing this would lead to a miss-
ing constraint during resolution, because no bundle exports these packages.)
The simplest approach is to add the coverage JAR file and its dependencies to the
launcher's class path and update the system packages. Next simplest is boot deleg-
ation: here you have the extra step of removing coverage packages from the Import-
Package of your instrumented bundle. Let's take the interesting route and turn the
coverage JAR file into a bundle. Our chosen coverage tool for this example is Cobertura
1.9.3 ( http:/ /cobertura.sourceforge.net/ ), but all the techniques mentioned should
work for other tools as well.