How do you add tests to legacy code?

Question

Accepted Answer

**Legacy code** (often untested, hard-to-change code) is challenging to test — it may have tangled dependencies and no tests. Adding tests safely involves techniques like **characterization tests**, **seams** for breaking dependencies, and incremental improvement, enabling safer changes.

## The challenge of legacy code

```text
Legacy code is often: untested, tightly coupled, hard to understand, risky to change:
  → no tests → changing it is dangerous (you can't tell if you broke something)
  → hard to test → dependencies are tangled (can't isolate units); not designed for testing
→ a chicken-and-egg problem: to change safely you need tests, but it's hard to test.
```

## Characterization tests (pin down current behavior)

```text
CHARACTERIZATION (golden master) tests → capture the code's CURRENT behavior as-is
  (even if you don't fully understand it / it has bugs):
  → write tests asserting what it ACTUALLY does now → a SAFETY NET
  → then you can refactor/change with confidence that behavior is preserved
→ Don't assert what it SHOULD do — assert what it DOES, to protect against regressions.
```

## Breaking dependencies (seams)

```text
To isolate hard-to-test code, find/create SEAMS (places to substitute dependencies):
  → extract dependencies behind interfaces; inject them; use the smallest safe refactors
    to make code testable (Michael Feathers' techniques)
  → carefully break dependencies so you can get the code under test, then test, then refactor
```

## Incremental approach

```text
✓ Add tests AROUND code BEFORE changing it (a safety net for the change)
✓ Focus on areas you're CHANGING / high-risk / high-value (not the whole codebase at once)
✓ Improve incrementally — leave code a bit better each time (the "boy scout rule")
✓ Use characterization tests to capture behavior, then refactor toward testability
```

## Why it matters

Understanding how to add tests to legacy code is valuable senior-level knowledge because **most real-world work involves existing, often-untested code**, and safely improving it is a common, important challenge, so it's practically relevant.

Legacy code (untested, tightly coupled, hard to change) presents a real **chicken-and-egg problem**: to change it safely you need tests, but it's hard to test (tangled dependencies, not designed for testing) — and changing untested code is dangerous because you can't tell if you broke something.

Understanding the techniques to address this is valuable practical knowledge. **Characterization tests** (capturing the code's *current* behavior as-is, asserting what it actually does rather than what it should — even if not fully understood) provide a **safety net** that lets you refactor and change with confidence that existing behavior is preserved — a key technique for working with code you don't fully understand.

Understanding **breaking dependencies via seams** (finding or creating places to substitute dependencies, using minimal safe refactors to make tangled code testable — the techniques from Michael Feathers' work on legacy code) is essential for getting hard-to-test code under test.

Understanding the **incremental approach** — adding tests around code before changing it (a safety net for the change), focusing on areas being changed or high-risk/high-value (not the whole codebase at once), and improving incrementally (the boy scout rule) — reflects the pragmatic, realistic way to improve legacy systems over time.

Since most real-world development involves existing, often-untested legacy code that must be changed safely (a common, challenging situation), and since understanding the techniques (characterization tests for a safety net, seams for breaking dependencies, incremental improvement) enables doing this, understanding how to add tests to legacy code is valuable senior-level knowledge — practically relevant for the common reality of working with existing untested code, reflecting the experience and techniques needed to safely improve legacy systems, an important competency for senior engineers who frequently must make untested code safer to change.