Hva er snapshot testing?

Question

Accepted Answer

**Snapshot testing** fanger et "snapshot" av et eller annet output (vanligvis en UI-komponents renderte output eller en datastruktur) og sammenligner fremtidige kjøringer mot det — og flagg når outputet endres. Det er nyttig for å oppdage utilsiktede endringer, men har begrensninger som er viktig å forstå.

## Hvordan snapshot testing fungerer

```text
1. First run → the test RECORDS the output (e.g. a rendered component) as a SNAPSHOT file
2. Later runs → COMPARE the current output to the saved snapshot:
   → MATCHES → pass; DIFFERS → fail (the output changed)
3. If the change is INTENTIONAL → UPDATE the snapshot (review the diff, then accept)
```

```js
// Jest snapshot test (e.g. a React component)
test('renders correctly', () => {
  const tree = render(<Button label="Click" />).toJSON();
  expect(tree).toMatchSnapshot();    // compares to the stored snapshot
});
```

## Bruk og fordeler

```text
✓ Detect UNINTENDED CHANGES — flags when output changes unexpectedly (UI, serialized data)
✓ FAST to write — no manual assertions for complex output; auto-captures the expected result
✓ Good for UI components (catch unexpected rendering changes), config, large data structures
```

## Begrensninger (bruk med forsiktighet)

```text
⚠️ Snapshots don't verify CORRECTNESS — they capture whatever output exists (even if WRONG);
   they only detect CHANGE, not that the output is RIGHT
⚠️ BLINDLY UPDATING snapshots (jest -u without reviewing) → defeats the purpose (accepting
   broken output) — a common bad habit
⚠️ Large/brittle snapshots → change often, get rubber-stamped, low value
→ Use for change detection; keep snapshots small/focused; REVIEW snapshot diffs;
  don't rely on them alone (combine with real assertions for behavior).
```

## Hvorfor det er viktig

Å forstå snapshot testing er verdifullt fordi det er en **vanlig brukt teknikk** (spesielt for UI) som er nyttig når den brukes riktig, men problematisk når den misbrukes, så å forstå både dens verdi og begrensninger er viktig praktisk kunnskap.

Snapshot testing — å fange output (vanligvis en rendert UI-komponent eller datastruktur) og sammenligne fremtidige kjøringer mot det lagrede snapshotet — er **nyttig for å oppdage utilsiktede endringer**: det flagg når output endres uventet (oppfanger utilsiktede UI-renderingsendringer eller datastrukturendringer), er **raskt å skrive** (auto-fanger forventet output uten å manuelt assert hver detalj av komplekst output), og passer til UI-komponenter, konfigurasjon og store datastrukturer.

Å forstå disse fordelene forklarer dens popularitet, spesielt innen UI-testing.

Men å forstå **begrensningene er kritisk viktig** for å bruke det godt: snapshots **verifiserer ikke korrekthet** — de fanger det outputet som finnes (selv om det er feil), oppdager bare *endring* ikke *riktighet* — så et snapshot kan låse inne feilaktig output.

Den **største fallgruven er blindt oppdatere snapshots** (kjøre oppdateringskommandoen uten å gjennomgå difftabellen), noe som opphever formålet ved å godta potensielt brutt output — en vanlig dårlig vane.

Store, skjøre snapshots som endres ofte blir stempel-godkjent og gir liten verdi.

Å forstå riktig bruk — for endringdeteksjon, holde snapshots små og fokusert, **gjennomgå snapshot diffs** nøye, og ikke stole på dem alene (kombinere med ekte atferdassertsjoner) — reflekterer modenhet som unngår vanlig misbruk.

Siden snapshot testing er mye brukt (spesielt for UI) og er nyttig for endringdeteksjon, men lett misbrukes (låser inne feilaktig output, blindt oppdaterer), og siden å forstå både dens verdi og dens viktige begrensninger gjør det mulig å bruke det godt, er forståelse av snapshot testing verdifull, praktisk relevant kunnskap — en vanlig teknikk å forstå korrekt, der å verdsette dens begrensninger (endringdeteksjon, ikke korrekthet) og riktig bruk (gjennomgå diffs, ikke blindt oppdaterer) er like viktig som teknikken selv, noe som reflekterer god testdommer.