Figure 8.2 Testing OSGi applications can be done in many ways. Any test process should include a simple
unit test phase, but the best way to do integration testing depends on a number of factors, including
which build tools are already being used.
Even if you need to reference OSG i classes directly, you may feel more comfortable
writing your application so that it doesn't have too many explicit OSG i dependencies.
After all, loose coupling is good, even when the coupling is to a framework as fabulous
as OSG i.
If you do have direct OSG i dependencies, using mocking frameworks to mock out
OSG i classes like BundleContext can be helpful. You can even mock up service look-
ups, although if you're using Blueprint or Declarative Services you'll probably rarely
have cause to use the OSG i services API directly. Using Blueprint has a lot of testability
advantages beyond eliminating direct OSG i dependencies.
One of the nice side effects of dependency injection frameworks like Blueprint is that
unit testing becomes much easier. Although Blueprint won't do your testing for you,
testing code that was written with Blueprint in mind is an awful lot easier than otherwise.
Separating out the logic to look up or construct dependencies from the work of
doing things with those dependencies allows dependencies to be stubbed out without
affecting the main control flow you're trying to test. The key is to realize that although
you certainly need a Blueprint framework to be present to run your application end to
end, you don't need it at all to test components of the application in isolation.
Search WWH ::