Igor's Blog

by Igor Stoyanov.

A strong principle of eXtreme Programming (XP) is the continuous integration aspect (see the Continuous Integration article by Martin Fowler). The traditional approach to the development of complex software has been to separate the development process into phases of coding, testing and integration. The continuous integration principle is to basically code, test and integrate at the same time, so that at almost any point in time, you have a working product.

In order to achieve this, you need to be able to automatically build your entire application, including running the unit and acceptance tests. Thus, tools such as Ant or Maven are the foundation for continuous integration.

Certainly, you need an actual unit testing framework to start with. I would not surprise anybody by choosing JUnit test framework for my unit testing frame work. It is so widely known and used that everything that I could say would be redundant. The only thing that I would like to add, although it is said by many other is that this framework is really very easy to understand and to use it.

The elegance comes when JUnit is integrated with Ant. This is the first step of achieving continuous integration. Actually, the fundamental benefit of continuous integration is that it removes situations where we are looking for bugs which could not be found during unit testing but would show up when we integrate the different parts in one whole system. These bugs are some of the hardest ones to find and only continuous integration testing could save us from a lot of headache in later phases of a project development. The integration of JUnit with Ant does exactly that.

Furthermore, because my project is a server-side application, I needed some framework for unit testing server-side code. I choose Cactus because it uses JUnit and could be integrated with Ant. The intent of Cactus is to lower the cost of writing tests for server-side code .Cactus implements an in-container strategy. I haven’t work with other testing frameworks for server-side code, but this was the framework that I had the most problems with from all other that I had used in my project until now. There were moments when I was very close to give up on it. I had so many problems only with configuring HSql database on JBoss server, but once I figured it out, I was wondering what took me so long. This wasn’t the case with Cactus framework. After been stacked with it for a long time, finally I succeed to make it work on both Tomcat and JBoss servers. Actually, most of the problems were on JBoss, but Tomcat wasn’t easy either. However, I am hoping for not having any problems with Cactus framework because I have no idea how I made it work. I am taking “once you made it work, just don’t touch anything anymore” approach with Cactus.

One of the problems was that there wasn’t implemented property in “cactus” task for JBoss.4.0.0 yet, so that I had to use the more complicated “runservertest” task. When this task is being used, it should be provided tasks for stopping and starting the current server.

However, I was very satisfied at the end. Although, Cactus framework was very difficult for me to configure and make it run, I found two very important bugs with Cactus testing that I would have very, very hard time finding. One of them was a bug that I had made. It was related to setup test data in the database. I had exchanged the roles for administrator and regular user. The strange thing was that when I tested via a web browser, everything worked fine, but Cactus find this data inconsistency. Otherwise, it would have shown up much later in the development of the project and would have created a lot of troubles for me. Just the thought about how much time I was going to spend on debugging for some minor bug like this, made me appreciate in-container unit testing as well as the continuous integration testing.

The second bug wasn’t mine! While cactus tests worked perfectly well on Tomcat server, they didn’t work on JBoss.4.0.0. It was very strange. The problem was in the statement:

request.isUserInRole(“user”);

JBoss.4.0.0 always returned false. After a lot of debugging and with the argument that this works on Tomcat, I started wondering about JBoss handling of “request.isUserInRole()”. I started searching the web and surprise, JBoss.4.0.0, which was released in this September (2004) has a bug and the statement above always returns false. Fortunately for me, somebody else found this bug, described in this post one week before me. There has been a patch released for this bug that could be found here.

Finding these two bugs convinced me very strongly for the need of in-container unit testing combined with continuous integration testing and for Test Driven Development as a whole. I will try to apply this kind of development very consciously and strictly in this as well as any future projects.