Chapter 10. Working with legacy code

 

This chapter covers

  • Examining common problems with legacy code
  • Deciding where to begin writing tests
  • Surveying helpful tools for working with legacy code

I once consulted for a large development shop that produced billing software. They had over 10,000 developers and mixed .NET, Java, and C++ in products, subproducts, and intertwined projects. The software had existed in one form or another for over five years, and most of the developers were tasked with maintaining and building on top of existing functionality.

My job was to help several divisions (using all languages) learn TDD techniques. For about 90% of the developers I worked with, this never became a reality for several reasons, some of which were a result of legacy code:

  • It was difficult to write tests against existing code.
  • It was next to impossible to refactor the existing code (or there wasn’t enough time to do it).
  • Some people didn’t want to change their designs.
  • Tooling (or lack of tooling) was getting in the way.
  • It was difficult to determine where to begin.

Anyone who’s ever tried to add tests to an existing system knows that most such systems are almost impossible to write tests for. They were usually written without proper places in the software (seams) to allow extensions or replacements to existing components.

There are several problems that need to be addressed when dealing with legacy code:

10.1. Where do you start adding tests?

 
 
 

10.2. Choosing a selection strategy

 

10.3. Writing integration tests before refactoring

 
 

10.4. Important tools for legacy code unit testing

 
 
 

10.5. Summary

 
 
sitemap

Unable to load book!

The book could not be loaded.

(try again in a couple of minutes)

manning.com homepage
test yourself with a liveTest