This is the second installment of OSGi-code-coverage post. Please read the first part: OSGi code coverage with Cobertura.

In this part I'll experiment with more than one bundle being code-coveraged, and I will also use Spring Dynamic Modules to activate the bundles (instead of BundleActivator that I used previously).

At work, we develop an application which makes heavy use of OSGi. And I need to test the bundles we write. Unit tests are not enough here, because the bundles interact a lot with filesystem and database(-s), so we need a plenty of integration/system tests here. I'm still struggling with the problem of how to organize the tests, how to fire them etc. Anyway, one of the things that I'd like to have is information about the code coverage. So, let's try.

This is a part of "Untestable code" series. See the introduction to know what is it all about (yes, you really should go there, do it).

The main idea of the series is to write unit-tests for a particularly nasty piece of code. In this part I will use JtestR library to write test cases... well, not exactly. The point is that you can't do it with JtestR. :(

This is a part of "Untestable code" series. See the introduction to know what is it all about (yes, you really should go there, do it).

The main idea of the series is to write unit-tests for a particularly nasty piece of code. In this part I will use JMockit library to write test cases.

This is a part of "Untestable code" series. See the introduction to know what is it all about (yes, you really should go there, do it).

The main idea of the series is to write unit-tests for a particularly nasty piece of code. In this part I will use JEasyTest library to write test cases.

This is a part of "Untestable code" series. See the introduction to know what is it all about (yes, you really should go there, do it).

The main idea of the series is to write unit-tests for a particularly nasty piece of code. This part will show how we can make testing possible thanks to some design sacrifices.

This is the first part of series of posts dedicated to the problems of unit-testing of some "untestable" code.

Sometimes, (more often than I'm ready to admit), I stumble over a piece of code which makes me doubt completely in my testing skills and sometimes even in unit testing in general. I've spend a lot of time trying to deal with such a "untestable" code. In this series of posts I'm gonna show you what I've learned.

Just a little comparison of jMock (ver 2.1.0) and EasyMock (ver. 2.2) libraries.