Test Driven Development with OSGi
A Practical Overview
Test Driven Development
1. Write test
2. Write code
3. Make it pass
OSGi Deployment
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 technolog...
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 t...
How to work successfully with OSGi
• Don’t develop directly against OSGi or have that
in your frequent development cycle, ...
Develop-Deploy-Test Cycle
Develop Develop
Continuous
Integration
Test Test
Test2Test1 Test3
Resolve
failed test
It wasn’t
...
A word about testing
• Don’t write unit tests that instantiate classes
as singletons, write functional tests that
instanti...
OSGi Service Pattern
API
Impl
Client
1. Register impl for intf
<osgi:service… />
2. Lookup impl of intf
<osgi:reference fi...
When to use mocks
• Use mocks when no alternative. For example,
try not to mock the persistence layer but
replace with in-...
Client running against OSGi
Manager
Service
OSGi
Auth
Service
Hibernate/
OpenJpa
My
Service
Postgres
Service
Client
Separa...
Test running against Jetty
Mock
Manager
Service
Jetty
Mock Auth
Service
Hibernate/
OpenJpa
My
Service
Service
Test
One
cla...
Code Coverage
• Few functional tests can provide good code
coverage without skewing the results or making it
impossible to...
Alternatives
• Focus more on value add services and less on
the platform. Services like identity and access
management etc...
Microservices Architecture
Service1 Service2 Service3 Service4
local store
Analytics
engine
Workflow
Message
Broker
Report...
Sample Project
• The Sample project demonstrate a layered project that can be
deployed on an OSGI container like Karaf wit...
Fini
Upcoming SlideShare
Loading in...5
×

TDD on OSGi, in practice.

1,241

Published on

The slides demonstrate how to work successfully with OSGi and discuss alternative architectures namely micro-services. Please like if you find the slides useful.

Published in: Technology, Education
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,241
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
28
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

TDD on OSGi, in practice.

  1. 1. Test Driven Development with OSGi A Practical Overview
  2. 2. Test Driven Development 1. Write test 2. Write code 3. Make it pass
  3. 3. OSGi Deployment 3. Watch it fail with error $%^#@ 2. Deploy on OSGi 1. Working code
  4. 4. 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 spent elsewhere My take: OSGi is like EJB2.0, a 3.0 incarnation is desperately needed. OSGi
  5. 5. 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.
  6. 6. How to work successfully with OSGi • Don’t develop directly against OSGi or have that in your frequent development cycle, it is mostly a deployment environment. • 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
  7. 7. Develop-Deploy-Test Cycle Develop Develop Continuous Integration Test Test Test2Test1 Test3 Resolve failed test It wasn’t me! Source control Short circuit deploy by embedding test container. PlansProgress Blockers Scrum update update checkin1+2
  8. 8. 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.
  9. 9. OSGi Service Pattern API Impl Client 1. Register impl for intf <osgi:service… /> 2. Lookup impl of intf <osgi:reference filter=… /> Export-Package Import-Package Import-Package OSGi Service Registry
  10. 10. 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 service interface. • Use spring to rewire mocks in.
  11. 11. Client running against OSGi Manager Service OSGi Auth Service Hibernate/ OpenJpa My Service Postgres Service Client Separate classloaders
  12. 12. Test running against Jetty Mock Manager Service Jetty Mock Auth Service Hibernate/ OpenJpa My Service Service Test One classloader InMem HSQL
  13. 13. Code Coverage • 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.
  14. 14. Alternatives • Focus more on value add services and less on the platform. Services like identity and access management etc • 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)
  15. 15. Microservices Architecture Service1 Service2 Service3 Service4 local store Analytics engine Workflow Message Broker Report engine STAGE PROCESS GENERATE API Gateway Service Registry PaaS request request App1 App2 Docker container Services Engine Shared store Cache Workflow
  16. 16. Sample Project • 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
  17. 17. Fini
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×