Legacy Adventures 1 -- Characterization Tests

Working with legacy code cannot be avoided. Even R & D and open-sourced projects tend to involve a lot of maintenance programming. Working with another programmer's code has become a rite of passage, and many find it tedious. I'm pretty sure any developer would rather write new code than work with old code.

For those of you with a more advanced understanding of programming, working with legacy code can be a rewarding exercise. For one thing, most legacy code tend to behave as expected. If you're fortunate enough to be maintaining something with unit tests, count yourself as lucky. However, if the code does not have tests, then it's time to write some.

Even if the legacy code already works, writing tests are still important. Your changes should not break existing functionality. Tests written this way are called characterization tests. Such tests will look like a waste of time at first, but at least you don't have to bother somebody from QA to know if something is awry.

For example, I recently had a project in VB6. The code generates XML from a formatted string. They wanted me to read the data in one set of nodes, look it up in a database, and then swap the data given a set of business rules. My characterization tests tested all the nodes that did not get their data swapped. I was now free to code the new functionality.

So, working with legacy code isn't really a bad thing. You can learn many lessons from legacy code. Assuming you're working with well-written code, you can learn how to program properly. And even if you're not working with properly written code, you can practice skills that will make you write better code, or at least learn which programming styles create headaches.

--Jon Abaca
Codelean programmer
and consultant