Mostrare quali test proteggono il comportamento

Questa lezione appartiene al Modulo 23 — Preparare la presentazione.

Obiettivo della lezione

Essere in grado di spiegare, durante la presentazione del Registro, quale test protegge quale comportamento — senza dover aprire il codice e cercare al momento. La mappatura è preparata prima.

Alla fine hai una tabella regola→test e sai nominare i test in modo che il nome stesso spieghi cosa proteggono.

Perché serve nel percorso

Durante la presentazione, il docente probabilmente chiederà: “come fai a sapere che questa regola funziona?” Se non hai la risposta pronta, devi cercare nei file — e questo dimostra che i test esistono ma non sono stati pensati come documentazione del comportamento.

Nel Registro del laboratorio

Le regole di dominio del Registro sono esplicite e verificabili. Ogni regola deve avere almeno un test che la protegge.

Tabella regola → test:

Regola di dominio	File di test	Nome del test
Strumento guasto non prestabile	test/application/registraPrestito.test.js	registraPrestito — lancia STRUMENTO_GUASTO_NON_PRESTABILE per strumento guasto
Strumento già in prestito non riprestabile	test/application/registraPrestito.test.js	registraPrestito — lancia STRUMENTO_GIA_IN_PRESTITO per strumento in prestito
Prestito già chiuso non chiudibile di nuovo	test/application/chiudiPrestito.test.js	chiudiPrestito — lancia PRESTITO_GIA_CHIUSO per prestito con chiusura impostata
Nome strumento vuoto non valido	test/application/registraStrumento.test.js	registraStrumento — lancia NOME_STRUMENTO_NON_VALIDO per nome vuoto
Ricerca per nome case-insensitive	test/application/cercaStrumenti.test.js	cercaStrumenti — trova strumento con nome maiuscolo cercando in minuscolo

Procedura guidata

1. Elenca tutte le regole di dominio del Registro (guarda src/domain/).
2. Per ogni regola, cerca il test corrispondente in test/.
3. Se il test manca: scrivilo adesso.
4. Se il test esiste ma ha un nome poco chiaro: rinominalo.
5. Compila la tabella regola→test nel README o in un documento separato.
6. Prepara la risposta verbale per la presentazione.

Attività in classe

Nomina correttamente questi test che hanno nomi poco descrittivi:

// Nomi da migliorare:
test("test 1", () => { /* ... */ });
test("errore strumento", () => { /* ... */ });
test("funziona", () => { /* ... */ });
test("guasto", () => { /* ... */ });

// Pattern da seguire:
// "[funzione] — [comportamento atteso] per [condizione]"
test("registraPrestito — lancia STRUMENTO_GUASTO_NON_PRESTABILE per strumento con stato guasto", () => { /* ... */ });

Poi costruisci la tua tabella:

## Tabella regole → test

| Regola | File test | Nome del test |
| --- | --- | --- |
| ... | ... | ... |

Spiegazione guidata per studiare

Un test con un buon nome è documentazione eseguibile. Quando leggi l’output di un runner di test, ogni riga è la prova che una regola vale:

✓ registraPrestito — lancia STRUMENTO_GUASTO_NON_PRESTABILE per strumento con stato guasto
✓ registraPrestito — lancia STRUMENTO_GIA_IN_PRESTITO per strumento in prestito
✓ chiudiPrestito — imposta la data di chiusura
✓ chiudiPrestito — lancia PRESTITO_GIA_CHIUSO per prestito già chiuso
✓ cercaStrumenti — restituisce tutti gli strumenti senza filtri
✓ cercaStrumenti — trova strumenti per nome case-insensitive

Questo output è quello che mostri durante la presentazione quando il docente chiede “i tuoi test funzionano?”. Non apri il codice — esegui i test e mostri il risultato.

La naming convention per il Registro:

[caso d'uso o funzione] — [comportamento atteso] per [condizione di test]

Esempi:

registraStrumento — salva lo strumento con stato disponibile
registraStrumento — lancia NOME_STRUMENTO_NON_VALIDO per nome di 1 carattere
registraPrestito — cambia lo stato dello strumento a in_prestito
chiudiPrestito — imposta chiusura con data corrente
cercaStrumenti — restituisce lista vuota se nessuno strumento corrisponde ai filtri

Come strutturare i test in gruppi:

// test/application/registraPrestito.test.js
describe("registraPrestito", () => {
  describe("caso felice", () => {
    test("salva il prestito con i dati corretti", () => { /* ... */ });
    test("cambia lo stato dello strumento a in_prestito", () => { /* ... */ });
  });

  describe("errori di dominio", () => {
    test("lancia STRUMENTO_NON_TROVATO per ID inesistente", () => { /* ... */ });
    test("lancia STRUMENTO_GUASTO_NON_PRESTABILE per strumento guasto", () => { /* ... */ });
    test("lancia STRUMENTO_GIA_IN_PRESTITO per strumento già in prestito", () => { /* ... */ });
  });
});

Passo per passo nel progetto

1. Esegui i test con npm test (o equivalente) e leggi l’output.
2. Identifica i test con nomi generici (test 1, funziona, errore).
3. Rinominali con il pattern [funzione] — [comportamento] per [condizione].
4. Raggruppa i test con describe per caso d’uso.
5. Compila la tabella regola→test nel README.
6. Esegui di nuovo i test e copia l’output nella tua presentazione come prova.

Prova di comprensione

• Qual è il vantaggio di un nome di test descrittivo rispetto a “test 1”?
• Come si risponde alla domanda “come verifichi che uno strumento guasto non venga prestato?”
• Perché i test raggruppati con describe sono più leggibili nella presentazione?
• Quante regole del Registro non hanno ancora un test?

Errori da evitare

• avere test con nomi come test("errore", ...) — non dicono cosa proteggono;
• avere test che passano per motivi sbagliati (non verificano davvero la regola);
• non eseguire i test prima della presentazione — potrebbero fallire per un bug introdotto dopo;
• confondere “test che passa” con “regola verificata” — un test mal scritto può passare anche se la regola è rotta.

Prodotto da consegnare

La tabella regola→test compilata, tutti i test con nomi descrittivi secondo la naming convention, e l’output del runner di test che dimostra che le regole principali del Registro sono protette.

Checklist di chiusura

• ogni regola di dominio del Registro ha almeno un test
• ogni test ha un nome nel formato [funzione] — [comportamento] per [condizione]
• i test sono raggruppati per caso d’uso con describe
• l’output del runner è leggibile e mostra le regole protette
• la tabella regola→test è nel README o nella documentazione di presentazione
• i test passano tutti prima della presentazione

Risultato atteso

Ho compilato la tabella regola→test per il Registro.
Ogni regola di dominio ha almeno un test con nome descrittivo.
L'output del runner mostra tutti i test che passano, ognuno con una regola specifica.
Durante la presentazione mostro l'output del runner come prova.
Il prossimo passo sarebbe aggiungere test per i casi limite non ancora coperti.