I was just recently faced with taunting task to revamping the transaction handling of the J2EE server without breaking it but improving performance and removing any resource leaks. Already two developers tried to do this but had problems to understand the existing code in the first place and so I failed, too. If we could not improve the code we had to dump the implementation and start all over again. Now just a few weeks before shipping I had to rewrite a central component without wasting other developer’s time and/or delaying the project. Lucky me jUnit came to the rescue. Instead of just starting to write a new implementation and then testing it I decided to write a test suite around the currently working code, replace the code and rerun the test suite ensuring that I did not break anything. Finally I had a chance to use test driven development (TDD).

As easy this sounds as difficult it was to implement. I spent around the same time for writing the test suite that to rewrite the transaction code but at the end testing was a breeze. The first hurtle was to decide how to test a transaction implementation because I did not want to rely on a DB, JMS etc and their side effects. So I wrote a fake XA resource that used JMS without transactions to trace the interactions with the transactions, various EJBs and 100+ tests. The first benefit from writing the test suite were a much better understanding of the transaction handling and its interaction with XA resources. At the end testing the new code was easy, straight forward and I missed one bug so far. The tests also made me very confident to put the code in the release branch without fearing to work on weekends just to fix undetected bugs.

So I have to give jUnit and TDD two thumbs up and see a beautiful friendship in the future. Nevertheless I have two little requests to the jUnit folks:

1. A way to write a message to the output file on a per test basis in order to write a description or other information out that later can be read and incorporate in a test suite report.
2. Currently there is only a successful or failed (failure or error) test result possible but sometimes it would be nice to keep non-crucial failures available but they should not fail the test suite. These warnings could be reported and even have a stack trace but would be considered a success. Examples of a warning could be a bug in a particular JDK or third party library that needs a work around but as soon as this is fixed the workaround should be removed or bugs that are postponed etc.