Hvordan tilføjer du tests til legacy code?

Question

Accepted Answer

**Legacy code** (ofte utestet, svært-at-ændre kode) er udfordrende at teste — det kan have rodet afhængigheder og ingen tests. Tilføjelse af tests sikkert involverer teknikker som **karakteriseringstests**, **seams** for at bryde afhængigheder, og trinvis forbedring, hvilket muliggør sikrere ændringer.

## Udfordringen med 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.
```

## Karakteriseringstests (fastlæg nuværende adfærd)

```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.
```

## Brud på afhængigheder (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
```

## Trinvis tilgang

```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
```

## Hvorfor det betyder noget

At forstå, hvordan man tilføjer tests til legacy code, er værdifuld viden på seniorniveau, fordi **det meste af virkelighedsarbejdet involverer eksisterende, ofte-utestet kode**, og sikker forbedring af det er en almindelig, vigtig udfordring, så det er praktisk relevant.

Legacy code (utestet, tæt koblet, svært at ændre) præsenterer et reelt **chicken-and-egg problem**: for at ændre det sikkert har du brug for tests, men det er svært at teste (rodet afhængigheder, ikke designet til testing) — og ændring af utestet kode er farlig, fordi du ikke kan se, om du har ødelagt noget.

At forstå teknikerne til at løse dette er værdifuld praktisk viden. **Karakteriseringstests** (opsamling af kodens *nuværende* adfærd som den er, påstand om hvad den faktisk gør snarere end hvad den burde — selv hvis ikke fuldt forstået) giver et **sikkerhedsnet**, der lader dig refaktorere og ændre med tillid til, at eksisterende adfærd bevares — en nøgleteknik for arbejde med kode, du ikke fuldt forstår.

At forstå **brud på afhængigheder via seams** (at finde eller skabe steder at erstatte afhængigheder, ved hjælp af minimale sikre refaktoreringer for at gøre rodet kode testbar — teknikerne fra Michael Feathers' arbejde med legacy code) er vigtig for at få svært-at-teste kode under test.

At forstå den **trinvise tilgang** — tilføjelse af tests omkring kode før ændring af den (et sikkerhedsnet for ændringen), fokus på områder, der ændres eller høj-risiko/høj-værdi (ikke hele kodebasen på én gang), og forbedring trinvist (the boy scout rule) — afspejler den pragmatiske, realistiske måde at forbedre legacy-systemer over tid.

Da det meste af udvikling i den virkelige verden involverer eksisterende, ofte-utestet legacy code, der skal ændres sikkert (en almindelig, udfordrende situation), og da forståelse af teknikerne (karakteriseringstests for et sikkerhedsnet, seams for at bryde afhængigheder, trinvis forbedring) muliggør dette, er forståelse af, hvordan man tilføjer tests til legacy code, værdifuld viden på seniorniveau — praktisk relevant for virkeligheden af at arbejde med eksisterende utestet kode, afspejlende den erfaring og de teknikker, der skal til for sikkert at forbedre legacy-systemer, en vigtig kompetence for senioringeniører, der hyppigt skal gøre utestet kode sikrere at ændre.