Costruire un caso minimo riproducibile

In parole semplici

Un caso minimo riproducibile (MCVE/MRE) è la versione più piccola del problema che mantiene il difetto. Niente fronzoli, niente codice estraneo, niente dipendenze inutili. Solo le righe necessarie per far comparire il bug, ogni volta.

Costruire un caso minimo è metà del lavoro di indagine. È anche la cortesia tecnica più alta verso chi ti aiuterà.

Parole nuove

• MCVE: Minimal, Complete, Verifiable Example.
• MRE: Minimal Reproducible Example (sinonimo moderno).
• bisezione: tecnica di riduzione che taglia a metà ad ogni passo.
• dipendenza spuria: import o codice che sembra necessario ma non lo è.

Cosa impari

• Eliminare codice e dati senza far sparire il bug.
• Distinguere ciò che fa parte del problema da ciò che è solo intorno.
• Produrre un file singolo che chiunque possa eseguire e vedere il difetto.

Le quattro proprietà del caso minimo

1. Minimal: solo il codice strettamente necessario.
2. Complete: include tutto ciò che serve per eseguirlo (import, dati).
3. Reproducible: il bug si vede ogni volta, non a caso.
4. Verifiable: chi lo riceve può confermarlo senza chiederti altro.

Manca anche solo una proprietà e il caso non serve.

Procedura di riduzione (bisezione)

Parti dal progetto reale che mostra il bug. Fai una copia di lavoro. Poi cicli:

1. Taglia a metà: rimuovi (o commenta) circa metà del codice/dati.
2. Esegui: il bug si vede ancora?
   • Sì → la metà tagliata era superflua. Continua a tagliare nella metà rimasta.
   • No → la metà tagliata conteneva qualcosa di necessario. Ripristina, poi taglia nell’altra metà.
3. Ripeti finché ulteriori tagli farebbero sparire il bug.

Dopo 6–8 bisezioni passi da 1000 righe a 50. Dopo 10 a meno di 20.

Cosa NON tagliare mai (almeno all’inizio)

• La sequenza esatta di chiamate che provoca il bug.
• I dati specifici che lo scatenano (un id, una stringa, un edge case).
• L’ordine degli eventi (timing, async).

Quando dubiti, taglia. Se il bug sparisce, ripristina. Nessun pezzo di codice è sacro.

Esempio: da 200 righe a 12

Partenza: app React di 200 righe, con router, autenticazione, store globale, lista prodotti. Bug: cliccando “Aggiungi al carrello” il totale non aggiorna.

Riduzione:

1. Rimuovi router → bug ancora presente.
2. Rimuovi autenticazione → bug ancora presente.
3. Riduci lista prodotti a 1 → bug ancora presente.
4. Rimuovi store globale → bug sparisce. Ripristina lo store.
5. Riduci lo store al solo carrello → bug ancora presente.
6. Riduci il componente al solo bottone “Aggiungi” e al totale → bug ancora presente.

Risultato: 12 righe, un solo componente, uno store con due campi. Il bug è chiaramente nella riduzione dello store. Indagine pronta.

Caso minimo “condivisibile”

Per chiedere aiuto, il caso minimo va dove altri possono provarlo:

• CodePen / JSFiddle / StackBlitz / CodeSandbox: per JS/web.
• Gist GitHub: per un singolo file.
• Repo Git pubblica: per casi multi-file.

Includi sempre:

• Comando per installare ed eseguire.
• Sezione “passi per riprodurre” anche nel README.
• Risultato atteso e osservato.

Esercizio guidato

Prendi un piccolo progetto (anche un esempio del tuo corso JavaScript) e introduci di proposito un bug ovvio (es. un < invece di <=).

1. Salva una copia di lavoro.
2. Applica la bisezione: taglia a metà, prova, ripristina o continua.
3. Ferma la riduzione quando un ulteriore taglio fa sparire il bug.
4. Conta le righe rimaste. Obiettivo: < 30.
5. Pubblica il caso su StackBlitz o in un gist.

Quando il caso minimo non basta a 30 righe

Alcuni bug nascono da combinazioni di componenti, framework, build, runtime. Se a 100 righe sei bloccato:

• Documenta cosa hai già tagliato e cosa non sei riuscito a tagliare.
• Documenta perché: ogni volta che togli X, sparisce il bug.
• Quella mappa è già un’ipotesi sulla causa.

Il principio sottostante

Il caso minimo non è il punto di arrivo dell’indagine. È il punto da cui l’indagine può finalmente partire.

Errori frequenti del principiante

• Tagliare prima di salvare la copia. Si rischia di perdere la riproducibilità in modo non recuperabile.
• Lasciare dipendenze inutili “per sicurezza”. Se non servono, distraggono.
• Cambiare codice mentre si taglia. Tagli e riscritture confondono: prima riduci, poi modifichi.
• Inviare 800 righe sperando che qualcuno faccia il lavoro. Quasi nessuno legge oltre la riga 50.