Cos'è lo snapshot testing?

Question

Accepted Answer

**Snapshot testing** cattura uno "snapshot" di un output (comunemente l'output renderizzato di un componente UI o una struttura dati) e lo confronta con esecuzioni future — segnalando quando l'output cambia. È utile per rilevare modifiche non intenzionali, ma ha limitazioni che è importante comprendere.

## Come funziona lo snapshot testing

```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
});
```

## Usi e vantaggi

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

## Limitazioni (usare con cautela)

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

## Perché è importante

Comprendere lo snapshot testing è prezioso perché è una **tecnica comunemente usata** (specialmente per la UI) che è utile quando applicata correttamente ma problematica se usata male, quindi comprendere sia il suo valore che le sue limitazioni è una conoscenza pratica importante.

Lo snapshot testing — catturare output (comunemente un componente UI renderizzato o una struttura dati) e confrontare esecuzioni future contro lo snapshot memorizzato — è **utile per rilevare modifiche non intenzionali**: segnala quando l'output cambia inaspettatamente (catturando accidentali modifiche nel rendering UI o cambiamenti nella struttura dati), è **veloce da scrivere** (catturando automaticamente l'output atteso senza asserire manualmente ogni dettaglio di output complesso), e si adatta bene a componenti UI, configurazioni e grandi strutture dati.

Comprendere questi vantaggi spiega la sua popolarità, specialmente nei test UI.

Tuttavia, comprendere le **limitazioni è criticamente importante** per usarlo bene: gli snapshot **non verificano la correttezza** — catturano qualsiasi output esistente (anche se sbagliato), rilevando solo il *cambiamento* non la *giustezza* — quindi uno snapshot può bloccare output difettoso.

Il **più grande rischio è aggiornare gli snapshot ciecamente** (eseguire il comando di aggiornamento senza revisione del diff), il che vanifica lo scopo accettando output potenzialmente danneggiato — un'abitudine cattiva comune.

Grandi snapshot fragili che cambiano spesso vengono timbrati e forniscono poco valore.

Comprendere l'uso appropriato — per il rilevamento dei cambiamenti, mantenendo gli snapshot piccoli e focalizzati, **revisionando attentamente i diff degli snapshot**, e non facendo affidamento su di essi da soli (combinando con vere asserzioni di comportamento) — riflette un giudizio maturo che evita l'uso scorretto comune.

Poiché lo snapshot testing è ampiamente usato (specialmente per la UI) ed è utile per il rilevamento dei cambiamenti ma facilmente frainteso (bloccando output errato, aggiornando ciecamente), e poiché comprendere sia il suo valore che le sue importanti limitazioni consente di usarlo bene, comprendere lo snapshot testing è una conoscenza preziosa e praticamente rilevante — una tecnica comune da comprendere correttamente, dove apprezzare le sue limitazioni (rilevamento dei cambiamenti, non correttezza) e l'uso appropriato (revisionare i diff, non aggiornare ciecamente) è importante quanto la tecnica stessa, riflettendo un solido giudizio nel testing.