Hvordan legger du til tester i arvet kode?

Question

Accepted Answer

**Arvet kode** (ofte utestet, vanskelig å endre kode) er utfordrende å teste — den kan ha rotete avhengigheter og ingen tester. Det å legge til tester på en sikker måte innebærer teknikker som **karakteriseringstester**, **seams** for å bryte avhengigheter, og gradvis forbedring, noe som muliggjør tryggere endringer.

## Utfordringen med arvet kode

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

## Karakteriseringstester (pin ned gjeldende oppførsel)

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

## Bryte avhengigheter (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
```

## Gradvis tilnærming

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

Å forstå hvordan du legger til tester i arvet kode er verdifull kunnskap på seniornivå fordi **det meste av arbeidet i den virkelige verden involverer eksisterende, ofte utestet kode**, og det å forbedre den på en sikker måte er en vanlig, viktig utfordring, så det er praktisk relevant.

Arvet kode (utestet, tett koblet, vanskelig å endre) presenterer et reelt **høna-og-egget problem**: for å endre den på en sikker måte trenger du tester, men det er vanskelig å teste (rotete avhengigheter, ikke designet for testing) — og det å endre utestet kode er farlig fordi du ikke kan fortelle om du ødelagde noe.

Å forstå teknikkene for å håndtere dette er verdifull praktisk kunnskap. **Karakteriseringstester** (som registrerer kodens *gjeldende* oppførsel som den er, påstår hva den faktisk gjør snarere enn hva den burde — selv om ikke fullstendig forstått) gir et **sikkerhetsnett** som lar deg refaktorisere og endre med tillit til at eksisterende oppførsel bevares — en nøkkelteknikk for å arbeide med kode du ikke helt forstår.

Å forstå **bryte avhengigheter via seams** (finne eller lage steder hvor du kan erstatte avhengigheter, bruke minimale sikre refaktoreringer for å gjøre rotete kode testbar — teknikkene fra Michael Feathers' arbeid med arvet kode) er essensielt for å få vanskelig-å-teste kode under test.

Å forstå **den gradvise tilnærmingen** — legge til tester rundt kode før du endrer den (et sikkerhetsnett for endringen), fokusere på områder som endres eller områder med høy risiko/høy verdi (ikke hele kodebsen på en gang), og forbedre gradvis (scoutregelen) — reflekterer den pragmatiske, realistiske måten å forbedre arvet systemer over tid.

Da det meste av utvikling i den virkelige verden involverer eksisterende, ofte utestet arvet kode som må endres på en sikker måte (en vanlig, utfordrende situasjon), og siden det å forstå teknikkene (karakteriseringstester for et sikkerhetsnett, seams for å bryte avhengigheter, gradvis forbedring) muliggjør dette, er det å forstå hvordan du legger til tester i arvet kode verdifull kunnskap på seniornivå — praktisk relevant for den vanlige virkeligheten med å arbeide med eksisterende utestet kode, reflekterende erfaring og teknikker som trengs for å gjøre arvet kode tryggere å endre, en viktig kompetanse for seniorer som ofte må gjøre utestet kode tryggere å endre.