Legacy systems carry the heaviest business logic and the highest change risk, yet they are usually the least tested. They were built before automated testing was routine, and their structure actively resists it: tangled dependencies, hidden state and no clean seams to test against. For technology leaders, the challenge is to introduce test automation into exactly the systems that need it most and accommodate it least, without grinding delivery to a halt in the process.
Why legacy systems resist testing
The defining feature of legacy code, in the practical sense, is that it lacks tests and is hard to add them to. Logic is interwoven with infrastructure, so a single function might read from a database, call an external service and update global state all at once. There are no clean interfaces to substitute, no obvious place to insert a test, and changing the code to make it testable feels risky precisely because there are no tests to catch a mistake. This is the central paradox: you need tests to change the code safely, but you need to change the code to add tests.
Accepting this reality is the starting point. You cannot test a legacy system the way you would test a greenfield one, and pretending otherwise leads to frustration and abandoned efforts. The strategy must be incremental, pragmatic and tolerant of imperfection, building coverage where it matters most rather than chasing a comprehensive suite that will never arrive.
Start with characterisation tests
Before changing legacy code, you often do not even know precisely what it does, only what it is supposed to do. Characterisation tests capture the current behaviour exactly as it is, including any quirks, so that you have a safety net before you start changing anything. They do not assert what the code should do; they record what it actually does. Once that net is in place, you can refactor with confidence, knowing that any change in behaviour will be flagged.
This approach is liberating because it sidesteps the need to fully understand the system before testing it. You pin down its observable behaviour, then improve the code beneath, gradually replacing characterisation tests with intentional ones as your understanding grows. It turns an intimidating, opaque system into something you can work with safely, one small area at a time.
Test at the seams you have
If unit testing is impractical because the code has no clean seams, test at a higher level. End-to-end and integration tests that exercise the system through its real interfaces, an API, a user journey or a batch process, can provide meaningful coverage without requiring you to untangle the internals first. These tests are slower and broader than unit tests, but for a legacy system they are often the only practical starting point, and they protect the behaviour that the business actually cares about.
As you build this outer layer of protection, you create the safety needed to begin introducing seams: extracting interfaces, breaking dependencies and making small areas of the code unit-testable. Over time the test pyramid grows from the top down, the opposite of greenfield development, because the outer tests come first and the finer-grained tests follow as the code becomes more tractable.
- Write characterisation tests to capture current behaviour before changing any legacy code.
- Begin with end-to-end and integration tests through real interfaces where unit testing is impractical.
- Prioritise coverage for the highest-risk, most-changed and most business-critical areas first.
- Introduce seams incrementally, breaking dependencies so small areas become unit-testable over time.
- Add a regression test for every bug fixed, so coverage grows naturally with the work you already do.
- Run the suite automatically in your pipeline so protection is continuous, not occasional.
Prioritise by risk, not by coverage
You will never test a large legacy system completely, so do not try. Direct your effort where it returns the most safety. Identify the areas that change most often, because those are where regressions are most likely. Identify the areas where a defect would cause the most business harm, because those are where protection matters most. Concentrate your initial testing there, and accept that stable, rarely touched code can remain untested for now. Coverage as a single percentage is a poor target; coverage of the code that actually carries risk is the goal.
This risk-based focus also makes the effort sustainable. A team that tries to test everything quickly burns out and gives up. A team that protects the dangerous parts first sees the benefit early, in fewer production incidents and more confident changes, which sustains the momentum to keep going.
Make testing a by-product of normal work
The most durable way to grow coverage is to fold it into work you are already doing. When you fix a bug, write a test that reproduces it first, so the fix is verified and the bug can never silently return. When you change a piece of code, add tests for that area as part of the change. This way, the parts of the system under active development steadily accumulate protection, while you avoid a separate, easily deprioritised testing project that competes with delivery for funding and attention.
Embed the suite in your delivery pipeline so it runs automatically on every change. Tests that run only when someone remembers provide little protection. Tests that run on every commit catch regressions immediately, while the cause is fresh and cheap to fix.
Common pitfalls
The usual mistakes include attempting a big-bang effort to test everything at once, which collapses under its own weight; chasing a coverage percentage rather than protecting the code that carries real risk; refactoring legacy code before any safety net exists, which introduces the very bugs testing was meant to prevent; and treating test automation as a separate project rather than a habit woven into delivery. Each of these turns a sound idea into a stalled initiative.
What good looks like
A healthy outcome is a legacy system whose most dangerous and most active areas are protected by automated tests that run on every change, with characterisation tests as a starting safety net and finer-grained tests growing where the team works most. Bugs come with regression tests, changes come with new coverage, and confidence to modify the system rises steadily. The system may never reach the test maturity of a greenfield project, but it becomes safe to change, which is the outcome that actually matters.
Introducing test automation into legacy systems is slow, deliberate work that pays back in reduced risk and faster, safer change. Need support applying this approach? Email sales@halfteck.com.