Working Effectively with Legacy Codes - notes

 Robert C. Martin Series

This series is directed at software developers, team-leaders,

business analysts, and managers who want to increase their

skills and proficiency to the level of a Master Craftsman.

The series contains books that guide software professionals

in the principles, patterns, and practices of programming,

software project management, requirements gathering,

design, analysis, testing, and others.

https://stackoverflow.com/questions/748503/how-do-you-introduce-unit-testing-into-a-large-legacy-c-c-codebase

https://docs.microsoft.com/en-us/archive/msdn-magazine/2009/december/generation-test-automated-unit-tests-for-legacy-code-with-pex

https://www.weeklydevtips.com/episodes/015

https://dzone.com/articles/introduction-test-driven

But using Test-Driven Development for legacy code is a little different from using TDD in a green-fields context. The general approach is identical:

1. Write a test to reproduce the error (test bar red)
2. Write code to fix the error (test bar green)
3. and then refactor (test bar still green)

However, when working with legacy code, you might need to do some refactoring upfront to make the code testable in the first place. In legacy code, it can be hard to write a unit test to reproduce a bug or to understand how a particular piece of code works, because it often contains embedded dependencies on other components which are hard (or impossible) to initialize in a unit testing context. Without breaking these dependencies, you have little option but to work with full integration tests. However, if you succeed in isolating the code you need to test from the surrounding components, there is no reason why you can't write effective unit tests to isolate, reproduce and fix bugs in legacy code.

In fact, Test-Driven Development (along with other related techniques such as Behaviour-Driven Development and Acceptance Test-Driven Development) is a valuable tool for working with legacy code. Test-Driven Development is not just an Agile practice; it is actually just common sense. Would you fly in an airplane where the pilot only ran through the pre-flight check list from time to time, or not at all, and fixed any issues that came up in the air? No, not really. Automated unit tests are like the checklist in a plane - they let you spot problems quickly, automatically, and with little effort on your part. Using Test-Driven Development with existing code is like finding and fixing issues using a pilot's checklist, rather then climbing onto the wing inflight and tightening a bolt or two.