Test Driven Development with OSGi
A Practical Overview
Test Driven Development
1. Write test
2. Write code
3. Make it pass
3. Watch it fail
with error $%^#@
2. Deploy on OSGi
1. Working code
Rod Johnson from Spring Source on
OSGi, Things I wish I knew…
• Over-invested in OSGi for 2 years
• Seduced by a technology in search
of a problem
• Clever technology but didn’t solve
most customers pressing problems
• Spent millions that could have been
My take: OSGi is like EJB2.0, a 3.0
incarnation is desperately needed.
Does investing in OSGi pay off?
OSGi is not easy to use and at the end of the day or year
depending on how long it takes to get things working, its value
is hard to see. This is why:
• Your application will not be more modular overall, on the contrary,
It ends up being not isolated from other applications since it is a
share everything instead of share nothing architecture.
• Versioning is pushed further down the stack, you wrestle with
maven transitive dependencies during build only to do that again at
runtime in OSGi.
• Most libraries are designed to work as libraries in the application
classloader not as bundles with their own classloader.
• OSGi is a dynamic service deployment framework (if you need one).
It is good for building platforms and for plugin architectures like
Eclipse where third party developers need to be sandboxed.
How to work successfully with OSGi
• Don’t develop directly against OSGi or have that
in your frequent development cycle, it is mostly a
• You can deploy on jetty inside a test just like the
one running inside OSGi without the overhead.
• Use spring dynamic modules vs blueprint to keep
bean config separate from osgi config
• Treat configuration as code and use Functional
tests with mocks if necessary
Short circuit deploy by embedding test container.
A word about testing
• Don’t write unit tests that instantiate classes
as singletons, write functional tests that
instantiate classes like they are configured.
• TDD helps you develop the API and test its
implementation using the proper contract.
• Reduce the surface area of the API.
• Remember the API is like a wide angle lens the
narrower the focal length the wider the scene
of the implementation.
OSGi Service Pattern
1. Register impl for intf
2. Lookup impl of intf
<osgi:reference filter=… />
When to use mocks
• Use mocks when no alternative. For example,
try not to mock the persistence layer but
replace with in-memory hsql database so that
your ORM and spring configuration are tested.
• OSGi services can easily be mocked using their
• Use spring to rewire mocks in.
Client running against OSGi
Test running against Jetty
• Few functional tests can provide good code
coverage without skewing the results or making it
impossible to refactor and identify dead code.
• The lack of code-coverage over a class is also
valuable information. For example missing
coverage on an exception class means missing
negative test cases.
• You wouldn’t test by throwing exceptions from a
unit test, that would be worst than having no
tests because it masks the need for one.
• Unit tests should follow the same logic.
• Focus more on value add services and less on
the platform. Services like identity and access
• Micro-services Architecture with a private
PaaS to bring services together and scale from
private to public clouds
• Use platform as a service like Apache Stratos
and deployment container like Docker.io
• And/Or OSGi (not exclusive technologies)
Service1 Service2 Service3 Service4
API Gateway Service Registry
Docker container Services Engine Shared store
• The Sample project demonstrate a layered project that can be
deployed on an OSGI container like Karaf without
compromising its ability to run on an embedded container like
jetty hosted inside an IDE or as part of a build and test cycle
performed by maven.
• The examples demonstrate the use of functional unit tests
that invoke the services via their restful interfaces over HTTP
achieving a complete assertion of their logic and configuration
via spring and cxf.
• Source: https://github.com/ielian