Unit Testing Legacy Code Example

I just started a project involving a fairly simple turn-based game. Unfortunately, I can't post any code or other identifying information, but I started to have some ideas that I thought might be useful to record on Wiki. Most of this will be point form. Feel free to contribute.


The original programmer had other more-pressing obligations and could not continue on the project. I have access to him for a short while via telephone before he has to leave town. I've had one telephone discussion to get an overview of the project organization.

I've done a PlanningGame session with my immediate OnsiteCustomer (who has a customer of her own, but is ultimately in charge of the creative aspects of the game). Her number one StoryCard was "No crashing." Since I don't know where the crashes may be coming from, I'm spending some time getting familiar with the code by adding UnitTests.

Oh, and I should mention that this is a one person project, so there's no one to do PairProgramming with.


The language I'm using is untyped and has a weak ObjectOriented model similar to JavaScript. It has garbage collection as well.

Random Thoughts

Far more important than refactoring and regression testing, I would ask "what, about the program, does the customer want changed?"

That's where you should start. -- JeffGrigg

The customer wants it "not to crash." ;-)

Is it crashing now? Can you make it crash on demand?

Only in the release version, which can't be debugged (due to the limitations of the language I'm using). Some conditions which cause it to crash are rare (such as one game piece type interacting with another type) and difficult to reproduce because of the randomness of the game. I believe that they will be easier to pinpoint as more tests are added and the code refactored to make testing easier.

You seem to be implying that I should just work on the code as it is and not bother with tests. But I may be reading into it differently than what you mean. Hypothetically speaking, let's say I just started fixing bugs. This is the same type of debugging as goes on in most shops, and we all know that it is CodeAndFix. This will not get the project finished on time, and it certainly won't make it easier to extend the game for a multiplayer version, which is the plan. The project is less than half done (time wise, not feature wise; remember the EightyTwentyRule), so it's not really a matter of just finding and fixing a couple of bugs. In my opinion, UnitTests are needed, and so is some ReFactoring. I'm not just doing this as an exercise; that would be a waste of my client's money.

Using unit tests as a means to getting to know the code can be very effective, so I think it's a very wise thing to do when new to a project. (And it has the nice side effect of building RegressionTests.)

I'm interested in hearing more about your progress, whoever you are. --PeterLindberg

My experience says crashes are usually (but not mostly) memory leaks with DivideByZero? rearing its head almost as often.... Perhaps you should look for array and pointer areas as places to start testing. Anyone else have pointers for this? It also sounds to me like getQuadEquivalent(x, y) returns something along the pattern of x * xLen + y -- which could be the tile #.

See also: UnitTestingLegacyCode

View edit of January 3, 2006 or FindPage with title or text search