Verifica regressioni dopo ogni passo

Questa lezione appartiene al Modulo 22 — Refactoring avanzato e varianti.

Obiettivo della lezione

Costruire il ciclo di verifica da eseguire dopo ogni singolo passo di refactoring nel Registro — non alla fine di tutti i passi, ma dopo ciascuno. Alla fine il ciclo è automatico e rapido: test, scenario, documentazione.

Perché serve nel percorso

La regressione è un comportamento che funzionava e poi si è rotto. Nel refactoring, accade quasi sempre quando si fa un passo troppo grande o si salta la verifica. Un ciclo di verifica dopo ogni passo riduce il costo della regressione: se qualcosa si rompe, sai esattamente quale passo l’ha causato.

Nel Registro del laboratorio

Il ciclo di verifica in tre fasi:

Fase 1 — Esegui i test automatici:

npm test

Tutti i test devono passare. Se uno fallisce, il passo ha rotto qualcosa — torna indietro prima di continuare.

Fase 2 — Percorri lo scenario manuale minimo:

Dopo ogni passo di refactoring, esegui questo scenario nel browser:

Scenario minimo di regressione per il Registro:

1. Apri il Registro nel browser.
2. Registra uno strumento (nome: "Test 001", categoria: "Misura").
3. Verifica che appaia nella lista.
4. Registra un prestito per quell'strumento.
5. Verifica che lo stato sia cambiato a "in prestito".
6. Chiudi il prestito.
7. Verifica che lo stato sia tornato a "disponibile".
8. Ricarica la pagina.
9. Verifica che i dati siano ancora presenti (persistenza).

Se uno di questi passi fallisce, il refactoring ha rotto qualcosa di visibile.

Fase 3 — Documenta nel commit:

git commit -m "refactoring: estrai verificaPrestabilità nel dominio

- comportamento invariato verificato: npm test (8/8 passano)
- scenario manuale: registra, presta, chiudi, ricarica — OK
- regressioni trovate: nessuna"

Procedura guidata

1. Esegui il passo di refactoring (una modifica piccola).
2. Esegui npm test — se fallisce, torna indietro.
3. Esegui lo scenario manuale minimo nel browser.
4. Se tutto funziona: fai il commit con il messaggio documentato.
5. Solo dopo: inizia il passo successivo.

Attività in classe

Costruisci il tuo scenario di regressione personalizzato per il Registro. Parti da quello minimo e aggiungi i casi specifici del tuo progetto:

## Scenario di regressione del Registro

Passi obbligatori (da eseguire dopo ogni refactoring):
1. Registra uno strumento → verifica nella lista
2. Registra un prestito → verifica stato "in prestito"
3. Chiudi il prestito → verifica stato "disponibile"
4. Ricarica → verifica persistenza

Passi aggiuntivi per il tuo progetto:
5. ...
6. ...

Verifica test automatici: npm test → __ test, __ passano

Spiegazione guidata per studiare

La verifica di regressione dopo ogni passo segue il principio della falsificabilità: se qualcosa va storto, devi poter dire con certezza “il problema è in questo passo” — non in uno dei 5 passi che hai fatto prima di accorgertene.

Regola pratica: un passo di refactoring non è completato finché non hai eseguito la verifica. Il commit è la sigla che dice “ho verificato, funziona”.

Cosa fare quando un test fallisce dopo il refactoring:

1. Non ignorare il test che fallisce.
2. Non correggere il test invece del codice (a meno che il test fosse sbagliato).
3. Usa git diff per vedere esattamente cosa hai cambiato nel passo.
4. Torna indietro (git stash o revert) e riparti da uno stato verificato.
5. Fai il passo in modo più piccolo.

Quanto spesso eseguire i test: dopo ogni passo di refactoring, anche se il passo sembrava piccolo. Un refactoring “sicuro” che rompe un test ha comunque rotto qualcosa.

Scenario manuale vs test automatici: i test automatici verificano le regole che hai esplicitamente codificato. Lo scenario manuale verifica l’integrazione — il collegamento tra UI, casi d’uso e persistenza che i test unitari non coprono.

Cosa coprono i test automatici:
✓ registraPrestito rifiuta strumenti guasti
✓ chiudiPrestito imposta la data di chiusura
✓ il mapping è corretto

Cosa copre lo scenario manuale:
✓ il form HTML è connesso al caso d'uso
✓ il messaggio appare nella pagina
✓ localStorage persiste dopo il ricaricamento

Entrambi sono necessari — uno non sostituisce l’altro.

Passo per passo nel progetto

1. Prima di iniziare il refactoring: esegui npm test e salva il numero di test passati.
2. Fai il primo passo di refactoring (piccolo).
3. Esegui npm test — confronta con il risultato precedente.
4. Esegui lo scenario manuale minimo.
5. Se tutto è verde: commit con messaggio documentato.
6. Ripeti dal passo 2 per il passo successivo.

Prova di comprensione

• Perché si verifica dopo ogni passo e non alla fine di tutti i passi?
• Cosa si fa quando un test fallisce dopo il refactoring?
• Qual è la differenza tra cosa verificano i test automatici e cosa verifica lo scenario manuale?
• Cosa deve contenere il messaggio di commit dopo un passo verificato?

Errori da evitare

• fare 3-4 passi di refactoring senza verificare tra uno e l’altro — se qualcosa si rompe, non sai quale passo è responsabile;
• correggere il test invece del codice quando il test fallisce — il test potrebbe essere corretto;
• saltare lo scenario manuale perché “i test passano” — i test unitari non coprono l’integrazione;
• non documentare la verifica nel commit — perdi la traccia di quando il progetto era in uno stato verificato.

Prodotto da consegnare

Lo scenario di regressione documentato, la sequenza di commit del refactoring con un commit per ogni passo verificato, e nessun test fallito durante il processo.

Checklist di chiusura

• lo scenario di regressione è scritto e testato prima di iniziare il refactoring
• dopo ogni passo: npm test passa, scenario manuale è percorso
• ogni commit contiene la nota della verifica eseguita
• nessun test fallisce durante il refactoring
• se un test è fallito: il passo è stato annullato e rifatto in modo più piccolo

Risultato atteso

Ho eseguito 4 passi di refactoring su registraPrestito.js.
Dopo ogni passo ho eseguito npm test (8/8) e lo scenario manuale (7/7).
Nessuna regressione trovata durante il processo.
Il repository ha 4 commit separati, ognuno con la nota di verifica.
Il comportamento del Registro è identico a prima del refactoring.