Testing applications - OSGi in Action - page 236

The first step is to create a new JAR file which contains the original Cobertura JAR
file and all of its execution-time dependencies. You embed these dependencies because
you want this to be a standalone bundle. Remember, this bundle will only be used during
testing, so you have more leeway than if you were creating a production-quality bundle.
You then use the bnd tool to wrap the JAR file in the same way you wrapped JU nit, making
sure you set Bundle-ClassPath so the bundle can see its embedded dependencies. You
can find the complete bundling process in cobertura.osgi/build.xml.
All you need to do now is instrument the classes and run the tests:

$ ant clean test.osgi -Dinstrument=true
You use the instrument property to enable the various instrumentation targets.
Before launching the tests, the build also sets the net.sourceforge.cobertura.data-
file system property so that instrumented tests know where to find the coverage data-
base. As soon as the tests complete, the build runs the Cobertura report task to
process the results. Point your browser at reports/index.html to see the results, which
should look like figure 7.4.

Coverage Report - All Packages

#
Classes

Package Line Coverage Branch Coverage Complexity

2.276
1.596
2.744

22
27
25

79%
86%
76%

64%
89%
60%

All packages
org.apache.commons.pool
org.apache.commons.pool.impl

2274/2870
564/649
1710/2221

657/1022
111/124
546/898

Report generated by Cobertura 1.9.3 on 2/21/10 7:47 PM

Figure 7.4 Cobertura coverage report for Commons Pool

In this section, you saw how to take existing tests (and test tools) and run them inside
an OSG i container. You may have noticed that this process is similar to the JAR -to-bundle
process described in the first half of chapter 6. Deciding how to bundle tests is no dif-
ferent than deciding how to bundle an application. Visibility and modularity are just as
important when it comes to testing. But what about going the other way? Can you take
OSG i-related code and test it outside the container?
When you first begin to modularize and migrate an application over to OSG i, you
probably won't have a direct dependency on the OSG i API . This means your code can
still be tested both inside and outside the container. But at some point you'll want to
use the OSG i API . It may start with one or two bundle activators, and then maybe use
the bundle context to look up a service. Dependency injection, component models
(discussed in chapters 11 and 12), and other similar abstractions can all help reduce
the need to deal directly with the container. But what if you have code that uses the
OSG i API ? Such code can't be tested outside the container—or can it?
Imagine if you could mimic the container without having to implement a com-
plete OSG i framework. There's a technique for doing this, and it goes by the name
of mocking .