Java Reference
In-Depth Information
Roll your
own
Pax Exam
Ant
Pax Exam
Code-
rst
rst or
code-first?
Maven
or Ant?
Begin
testing
Unit test
Maven
Roll your
own
Manifest-
rst
Maven
Maven
or Ant?
Tycho test
Ant
Roll your
own
Pax Exam
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.
BLUEPRINT-DRIVEN TESTING
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.
