OSGi - Automated, unit and integration tests with JUnit

Article to show how to build automated integration tests with JUnit in a OSGi environment

OSGi is a brilliant architecture. Amazing softwares with complex architectures and hundred of components, like Eclipse Platform, are possible to build thanks to the OSGi architecture.

Test is essencial for software development, and continuos integration is what every profitful enterprise needs, because, when earlier the error is discovered, it's cheaper to fix it.

How does we can test the interfaces and behaviors of a encapsulated OSGi component? The answer is on this page.

Introduction

For CBD (Componente Based Development) and SOA, OSGi is a very good choice. In a lot of enterprises, the biggest problem is how to develop a system that fits all needs of all the customers. Some enterprises solve this with a kind of generic application that has hundred of parameters where you can customize the behavior and UI at runtime. So, this is not the best approach, it's a very expensive way. With OSGi, complex applications, like Eclipse, can be made in a cheap and reusable way, and this is what we look for.

There are several ways to test OSGi components, next it'll be demonstrated one of them. To understand what is being discussed, first you must to know these technologies. All used technologies are referenced with links at the bottom of the article. 

iPOJO and JUnit4OSGi

As in the project page: 

iPOJO is a service component runtime aiming to simplify OSGi application development. It natively supports ALL the dynamism of OSGi. Based on the concept of POJO, application logic is developed easily. Non-functional properties are just injected in the component at runtime.

iPOJO project is a set of some subprojects. What interest us for now is the JUnit4OSGi framework, that allowing the execution of JUnit tests in an OSGi environment.

To test your application, just follow these steps:

The fragment that will test the host bundle

1. Prepare the OSGi environment. Put the JUnit4OSGi and JUnit bundles in the right folder ("plugin" folder if equinox, for example). Note that in JUnit4OSGi framework are two test runners, one graphical and other that show the results on the command line, choose one of them. The JUnit 4 is not supported by iPOJO for now, so, we must to use JUnit 3.
2. You must to have at least two bundles. One bundle is the normal implementation, that solves a problem. Other bundle, is a fragment bundle that has just the JUnit testes. You need to create a Fragment bundle referencing the bundle you want to test. To do this, just put Fragment-Host: <host bundle symbolic name> in the MANIFEST.MF file of the fragment bundle. The fragment bundle will see all classes of the host bundle, even that are not declarated public in the manifest file.
3. In the fragment bundle, create the JUnit Test cases and a normal JUnit Test suite.
4. In the host bundle, inform the "Test-Suite" parameter. Ex.: Test-Suite: com.edpichler.test.MySuite.

To run the tests, start the OSGi environment and go to the GUI of the Test Runner you choosed, and start the tests. If you choosed a command line test runner, the tests will start automatically.

See a example running in this example on GitHub.

Troubleshooting

If you are under Mac OS X, maybe have some problems to run the Swing Test Runner. This is because some dead lock problem in SWT/AWT native implementation related here.

Solution: Just put this additional argument to run without problems: --launcher.secondThread

References

1. RCP Quick Start Blog. Accessed in 29, november 2010.
   RCP Quick Start Blog
2. Apache IPojo Framework. Accessed in 29, november 2010.
   Apache IPojo Framework
3. CBD on Wikipedia. Accessed in 29, november 2010.
   Component Based Development
4. GitHub, Address Service Component project. Accessed in 29, november 2010.
   GitHub, Address Service Component project
5. JUnit Framework. Accessed in 20, november 2010.
   JUnit Framework.
6. Apache Felix. Accessed in 29, november 2010.
   Apache Felix
7. OSGi Alliance. Accessed in 23, november 2010.
   OSGi Alliance