Hur lägger du till tester för legacy-kod?

Question

Accepted Answer

**Legacy-kod** (ofta otesterad, svår-att-ändra-kod) är utmanande att testa — den kan ha förvirrande beroenden och inga tester. Att lägga till tester på ett säkert sätt kräver tekniker som **karaktäriseringstester**, **seams** för att bryta beroenden, och inkrementell förbättring, vilket möjliggör säkrare ändringar.

## Utmaningen med legacy-kod

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

## Karaktäriseringstester (fastställ nuvarande beteende)

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

## Bryta beroenden (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
```

## Inkrementell metod

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

## Varför det är viktigt

Att förstå hur man lägger till tester för legacy-kod är värdefull kunskap på seniornivå eftersom **det mesta verkliga arbete involverar existerande, ofta otesterad kod**, och säker förbättring är en vanlig, viktig utmaning, så det är praktiskt relevant.

Legacy-kod (otesterad, tätt kopplad, svår att ändra) presenterar ett verkligt **höna-och-ägg-problem**: för att ändra den på ett säkert sätt behöver du tester, men det är svårt att testa (förvirrande beroenden, inte designad för testning) — och att ändra otesterad kod är farligt eftersom du inte kan se om du bröt något.

Att förstå teknikerna för att hantera detta är värdefull praktisk kunskap. **Karaktäriseringstester** (fångar kodets *nuvarande* beteende som det är, hävdar vad den faktiskt gör snarare än vad den borde — även om det inte är helt förstått) ger ett **skyddsnät** som låter dig refaktorera och ändra med förtroende att existerande beteende bevaras — en nyckelteknik för att arbeta med kod du inte helt förstår.

Att förstå **bryta beroenden via seams** (hitta eller skapa platser för att ersätta beroenden, använd minimala säkra refactorings för att göra förvirrande kod testbar — teknikerna från Michael Feathers arbete med legacy-kod) är väsentligt för att få svår-att-testa kod under test.

Att förstå den **inkrementella metoden** — lägg till tester runt kod före ändring (ett skyddsnät för ändringen), fokusera på områden som ändras eller högrisk/högt värde (inte hela kodbasen på en gång), och förbättra inkrementellt (scout-regeln) — reflekterar det pragmatiska, realistiska sättet att förbättra legacy-system över tid.

Since de flesta verklig utveckling involverar existerande, ofta otesterad legacy-kod som måste ändras på ett säkert sätt (en vanlig, utmanande situation), och eftersom förståelse för teknikerna (karaktäriseringstester för ett skyddsnät, seams för att bryta beroenden, inkrementell förbättring) möjliggör detta, är förståelse för hur man lägger till tester för legacy-kod värdefull kunskap på seniornivå — praktiskt relevant för den vanliga verkligheten av att arbeta med existerande otesterad kod, reflekterar erfarenheten och teknikerna som behövs för att säkert förbättra legacy-system, en viktig kompetens för senioringenjörer som ofta måste göra otesterad kod säker att ändra.