Responsibilities of the Test-Driven Developer in a Legacy Code Base

This is a follow-up question from an attendee of a recent TDD for Embedded C++ training course.

What exactly is a person’s responsibility for unit testing when they go into existing untested code?

Like all good questions in software development, the answer is “it depends”.


The Boy Scout rule kind of sums it up. Leave the campground better than you found it. You also have to be practical. Each iteration (or story) should include some improvement work. Do something reasonable that supports people learning the place for unit tests, TDD, and refactoring. For example:

A given story requires changes to 3 modules that currently do not have tests. How do we handle it? You have options:

1) The old way, make the changes and pray. — then you will learn nothing and your code will continue to degrade.

2) Write tests for all three modules so they are completely understood and tested. — Now you might miss important deadlines if these three modules are troubled by complexity and dependency. Your organization might start blaming your new way of working.

3) Do something pragmatic that supports improvement and learning. — Module B has the most changes and is complex. Module C has only a small change but is complex. Module C rarely changes. Module A has a moderate size change and we judge that it can be safely manually tested. We have not changes A for years and we don’t see changes on the horizon.

Pragmatic Choice

Option three sounds like the pragmatic choice, possibly treated like this:

  • Pull B into the test environment.
  • Write some test to understand the area we are about to change.
  • Look for possible side effects and write a few tests for those.
  • Envision some design improvement that would have made the change easy to add. Do some refactoring in that direction.
  • Test-drive in the new changes.
  • See if A’s changes are really another responsibility that you’d be pulled out of A and test driven as a separate module.

Without tests you are guessing that you know what the code is doing. I like to think that adding tests helps the developer become qualified to change the code.

Budget improvement work

You might want to budget (time-box?) improvement work. Every iteration spend one day on improvement work related to the iteration’s stories or some design goal. You might want to have people report the improvement work periodically. You might want to develop an architectural vision of where the team sees the design in the next year, or two.

How much improvement work is the right amount. 0% is too little and 100% is too much. Treat it as a strategic initiative.

You may decide in some cases that you do not have time to do improvement work. Move towards that being the exception, rather than the rule.

Leave a Reply

Your email address will not be published.

Be gone spammers * Time limit is exhausted. Please reload the CAPTCHA.