GridGain - Cloud Development Platform

Dark Side Of Diligent Unit Testing

I’m not going to discuss merits of Test-Driven Development (TDD), whether or not you really write tests first and how often. I think we can all agree that unit testing (as part of the overall, much larger testing strategy) is a key component of any serious software project and probably the most important aspect of any Agile project where frequent commits, build-per-commit and instant feedback from the build are the key ingredients.

Lately, I’m seeing (figuratively speaking) more and more projects that have hundreds upon hundreds of unit tests. Usual environment for these tests involves developers running some subset of these unit tests as they develop locally on their workstations and build happens on some juiced-up server where all JUnits are run every time build is made.

What I still see is that people run builds only at night or just several times per day. The reason? "The freaking thing takes X hours to complete(!!)" - is usual response. Teams that have only nightly or otherwise infrequent builds are highly inefficient:

• It is taking a whole day of commits before they can even spot an integration problem or problem in some subsystem that nobody cared to run test for
• As a consequence fixing the problem takes by definition more than one calendar day and often the actual place (and troublesome code revision) is hidden by consequent commits
• Fixing broken build becomes a torture as you need to wait for the same X hours to confirm whether or not you fixed the build
• Visibility into the project is delayed by at least a day
• Employing off-shore teams gets ugly as they often given broken build or producing broken build depending from which side you are looking at it

But what can you do? "It takes Ant about 10 minutes to build the branch and then junits run for 5 hours straight. Thank God if nothing is broken otherwise we have to wait another 5 hours for re-run..." – is the usual sentiment. Think about: how often have you heard this explanation…

One thing you can do rather quickly (meaning in the matter of hours in most cases) is to grid enable your JUnits and run those unit tests that can be run concurrently - in parallel on the grid. I would go on the record saying that over 90% of your JUnits would usually qualify to run concurrently. And that means that you have got an embarrassingly parallel problem on your hands and products like GridGain can easily solve it for you.

With upcoming release of GridGain 1.6 you can grid enable your JUnit literally in minutes (see one of my blogs posted on Monday). Install GridGain on as many nodes as you like (simple unzipping takes less than a minute per node) and then change the test suite class for ours. In most cases that’s it there is to it. Note that Junit3 and JUnit 4 will be supported out of the box.

After GridGain 1.6 is out I will come with a screencast that will show all these simple steps. Meanwhile, you can download GridGain 1.5 and enjoy grid computing in its original, intended form :-)

Posted at 10:01AM Sep 26, 2007 by Nikita Ivanov in Technology  |  Comments[1]