Tools for building and testing - Enterprise OSGi in Action - page 208

plug-in automatically generate a manifest based on the .eba contents and the pom
symbolic name, set generateManifest to true.
Whichever style of OSG i build you go for—manifest-first or bundle-first, Maven or
Ant, tightly integrated to your IDE or relatively standalone—compiling and packaging
up your OSG i bundles and applications should only be the first half of your build auto-
mation. The second, equally important, half is automated testing. As with compiling,
testing OSG i bundles presents some unique challenges, and a range of tools have
sprung up to help.

8.3 Testing OSGi applications

If you're like a lot of developers, you'll probably divide your testing into a few phases.
The lowest-level tests you'll run are simple unit tests that exercise individual classes,
but not their interactions with one another. The next group of tests in your test hierar-
chy are the integration tests, which test the operation of your application. Finally, at
the highest level, you may have system tests, which test the complete system, prefera-
bly in an environment that's close to your production one.
When you're testing OSG i bundles, each of these types of testing requires a differ-
ent approach—different from the other phases, and also different from how you'd do
similar testing for an application intended to run on a Java EE server or standalone.
We'll start by discussing unit testing, because that's the simplest case in many ways.
We'll then show you some tools and strategies that we hope you'll find useful for inte-
gration and system testing.
Unit testing OSG i bundles is straightforward, but you'll find you've got choices to
make, and a bewildering array of tool options when you start looking at integration
testing. The good news is that if you've already decided how to build your bundles,
some of the choices about how best to test them will have been made for you. The bad
news is that you've still got a few choices! Figure 8.2 shows some of these choices.

8.3.1 Unit testing OSGi

By definition, unit tests are designed to run in the simplest possible environment. The
purest unit tests have only the class you're testing and any required interfaces on the
classpath. In practice, you'll probably also include classes that are closely related to
the class that's being tested, and possibly even some external implementation classes.
But unit tests needn't—and shouldn't—require big external infrastructure like an
OSG i framework.
How can code that's written to take advantage of the great things OSG i offers work
without OSG i? How can such code be tested? Luckily, the answer is easily .

MOCKING OUT
If you followed our advice in chapter 5, you probably don't have many explicit depen-
dencies on OSG i classes in your code. The enterprise OSG i features of your runtime
environment will ideally be handling most of the direct contact with the OSG i libraries
for you.