I've been reading the Extreme Programming literature and I'm looking to adopt some of their development procedures. Unit tests seem like the first step missing from my current project. The problem is, where to begin? Our system currently has tons of asserts and debug code, but no unit tests. How do you retrofit unit tests in an existing system?

The biggest challenge is that the project is a complex distributed system. How do you unit test a system that requires a web server, a SQL server, three different application servers, and two client programs to create the full user experience? Needless to say, debugging is not easy! :)

-- Anonymous, February 09, 2001

Answers

Of course, the most effective way to unit test is to do it right from the very start. Unit testing is as much a design tool and a method for getting things right the first time than it is anything else.

Once a big system is in place, unit testing becomes a lot more painful and it takes quite awhile before time invested in testing all of your code reaches the break even point. Depending on how much more developing there is to be done, it may not be worth to you. It may behoove you to leave that up to the poor sap who gets put in charge of maintaining the system. If you're that poor sap, then roll up your sleeves and get ready to work.

You say "its a big system, how do I test it?" The answer is you don't test the system - system tests are something entirely different.

You test it piece by piece, starting with any subsystems you consider to be fragile. If you are writing in an OO style, you would normally test on a per class basis, exercising all aspects of every public interface, deliberately trying to break them. Its more art than science to do this efficiently - you want tests for things that could break in ways people didn't anticipate, and that's not an easy job. You will immediately find that a brain dead brute force approach is not feasible - you will have to be more clever than that.

My basic rule of thumb is that whenever I am tempted to put debug code in, its time to write a test. The test then lives with the code forever. It also doesn't munge up your code base with all sorts of debug code that may or may not be needed in the future (which eliminates the "cleanup" wars), and I never need to inspect the output of the debug code - the tests are always automated. Whenever I find a bug, its definitely time to write a test. Every day at lunch, its time to run the tests. Every day before I go home, its time to run the tests. Try it, you may like it.

Bob

-- Anonymous, February 13, 2001