Verificare segnalazione guasto e stati

Questa lezione appartiene al Modulo 23 — Verifica finale prima della consegna.

Il ciclo di vita di uno strumento guasto è il percorso più lungo del Registro: disponibile → guasto → in manutenzione → disponibile. Ogni transizione deve funzionare correttamente e deve produrre lo stato giusto nel JSON di localStorage. Questa verifica manuale va completata prima della presentazione.

Obiettivo della lezione

In questa lezione esegui una verifica manuale sistematica della segnalazione di guasto e di tutte le transizioni di stato dello strumento nel Registro. Verifichi ogni passo del ciclo guasto → manutenzione → disponibile e documenti il comportamento del sistema.

Alla fine devi avere un risultato verificabile: la checklist completata e la capacità di mostrare ogni transizione in DevTools durante la presentazione.

Il ciclo di vita da verificare

Il percorso completo che devi verificare è:

FASE 1 — Strumento disponibile
  Stato iniziale: disponibile
  Azione: nessuna ancora
  Atteso in DevTools: { stato: "disponibile" }

FASE 2 — Segnalazione guasto
  Azione: clicca "Segnala guasto" sullo strumento
  Atteso: stato cambia da "disponibile" a "guasto"
  Atteso in DevTools: { stato: "guasto" }
  Atteso in UI: lo strumento appare nella lista come "guasto"
  Atteso: lo strumento non compare nella lista dei prestabili

FASE 3 — Avvio manutenzione
  Azione: clicca "Avvia manutenzione" sullo strumento guasto
  Atteso: stato cambia da "guasto" a "in_manutenzione"
  Atteso in DevTools: { stato: "in_manutenzione" }

FASE 4 — Completamento manutenzione
  Azione: clicca "Manutenzione completata"
  Atteso: stato cambia da "in_manutenzione" a "disponibile"
  Atteso in DevTools: { stato: "disponibile" }
  Atteso in UI: lo strumento riappare nella lista dei prestabili

Scenari aggiuntivi da verificare

Oltre al percorso principale, verifica questi scenari limite:

Scenario G1 — Guasto durante prestito
  Setup: strumento in_prestito
  Azione: segnala guasto
  Atteso: transizione da "in_prestito" a "guasto" permessa
  Atteso: il prestito aperto viene gestito (chiuso o segnalato)

Scenario G2 — Tentativo di prestito su strumento guasto
  Setup: strumento con stato "guasto"
  Azione: tenta di avviare un prestito
  Atteso: messaggio di errore "Lo strumento non è disponibile"

Scenario G3 — Transizione non valida
  Setup: strumento con stato "guasto"
  Azione: tenta di segnalarlo "disponibile" direttamente senza manutenzione
  Atteso: transizione rifiutata (non deve essere possibile dalla UI)

Scenario G4 — Messaggio dopo segnalazione
  Azione: segnala guasto su strumento disponibile
  Atteso: messaggio di conferma visibile ("Guasto segnalato")

Procedura guidata

1. Apri il Registro nel browser con DevTools → Application → Local Storage visibile.
2. Registra uno strumento nuovo: “Sega circolare”, categoria “elettrico”.
3. Segnala un guasto su quello strumento e osserva il cambio di stato in DevTools.
4. Verifica che lo strumento non appaia nella lista dei prestabili.
5. Avvia la manutenzione e osserva il cambio di stato.
6. Completa la manutenzione e verifica che torni disponibile.
7. Esegui gli scenari G1-G4 e documenta ogni risultato nella scheda.

Attività in classe

Usa questa scheda come foglio di verifica:

## Verifica manuale — Segnalazione guasto e stati

Data: _______________
Browser usato: _______________

PERCORSO PRINCIPALE
[ ] Fase 1 — Strumento disponibile: DevTools mostra { stato: "disponibile" }
[ ] Fase 2 — Segnalazione guasto: stato diventa "guasto" in DevTools e in UI
[ ] Fase 2 — Strumento guasto escluso dai prestabili
[ ] Fase 3 — Avvio manutenzione: stato diventa "in_manutenzione"
[ ] Fase 4 — Completamento: stato torna "disponibile", strumento prestabile

SCENARI LIMITE
[ ] G1 — Guasto durante prestito: transizione gestita correttamente
[ ] G2 — Tentativo prestito su guasto: messaggio di errore visibile
[ ] G3 — Transizione non valida: impossibile dalla UI o errore esplicito
[ ] G4 — Messaggio di conferma dopo segnalazione: visibile e leggibile

Difetti trovati:
1. _______________
2. _______________

Difetti corretti:
1. _______________
2. _______________

Se lavori in gruppo, una persona esegue le azioni nella UI e un’altra osserva DevTools e compila la scheda.

Spiegazione guidata per studiare

Il ciclo guasto → manutenzione → disponibile è il percorso che dimostra meglio che le transizioni di stato sono controllate. Se potessi passare direttamente da “guasto” a “disponibile”, la manutenzione sarebbe solo un’opzione facoltativa invece di un passaggio obbligatorio. Questo potrebbe avere senso o meno nel laboratorio reale, ma la cosa importante è che sia una scelta esplicita e verificabile.

Quando esegui la verifica, tieni sempre DevTools aperto. Ogni cambio di stato deve essere visibile nel JSON di localStorage, non solo nell’interfaccia. Se la UI mostra “guasto” ma localStorage ha ancora “disponibile”, c’è un disallineamento tra ciò che viene mostrato e ciò che viene persistito.

Il caso G1 — guasto durante un prestito — è il più delicato. Cosa succede al prestito aperto quando lo strumento viene segnalato guasto? Il Registro deve avere una risposta definita. Non importa quale risposta, purché sia consistente e documentata.

Il caso G3 — transizione non valida — è importante per la presentazione. Se la UI permette di andare direttamente da “guasto” a “disponibile”, significa che la regola verificaTransizione nel dominio non viene rispettata. Questo è un difetto architetturale da correggere prima della consegna.

Quando prepari la presentazione, usa la verifica di questo ciclo come dimostrazione pratica: mostra ogni transizione in diretta, con DevTools aperto, commentando il cambio di stato nel JSON. È la prova più concreta del funzionamento dell’architettura.

Passo per passo nel progetto

1. Apri application/segnalaGuasto.js (o equivalente) e verifica che chiami verificaTransizione prima di aggiornare lo stato.
2. Apri domain/regolePrestito.js e verifica che la transizione guasto → in_manutenzione sia nella mappa delle transizioni valide.
3. Verifica che la transizione guasto → disponibile non sia presente nella mappa.
4. Apri il browser, registra uno strumento e segui il ciclo completo.
5. Dopo ogni transizione, copia il JSON da DevTools e verifica che lo stato corrisponda.
6. Esegui gli scenari limite G1-G4.
7. Documenta qualsiasi differenza tra il comportamento atteso e quello osservato.

Esempio da leggere lentamente

Questo codice mostra come la segnalazione di guasto rispetta le regole di dominio:

// application/segnalaGuasto.js
import { verificaTransizione } from '../domain/regolePrestito.js';
import { StatoStrumento } from '../domain/StatoStrumento.js';
import { archivioStrumenti } from '../infrastructure/archivioStrumentiLocale.js';

function segnalaGuasto(idStrumento, motivo) {
  const strumento = archivioStrumenti.trova(idStrumento);
  if (!strumento) {
    throw new Error('Strumento non trovato');
  }

  // verificaTransizione lancia errore se la transizione non è permessa
  // es. IN_MANUTENZIONE → GUASTO non è permessa
  verificaTransizione(strumento.stato, StatoStrumento.GUASTO);

  archivioStrumenti.aggiornaStato(idStrumento, StatoStrumento.GUASTO);

  // opzionale: registra il motivo del guasto nei metadati
  if (motivo) {
    archivioStrumenti.aggiornaMotivo(idStrumento, motivo);
  }

  return archivioStrumenti.trova(idStrumento);
}

Nota: verificaTransizione viene chiamata prima di aggiornare lo stato. Se la transizione non è permessa, lo stato non cambia e l’errore viene propagato alla UI. Questo garantisce che lo stato in localStorage sia sempre coerente con la mappa delle transizioni valide.

Prova di comprensione

Prima di chiudere la lezione, rispondi per iscritto a queste domande:

• Perché uno strumento in manutenzione non può tornare direttamente disponibile saltando la verifica?
• Se segnalaGuasto non chiama verificaTransizione, quale scenario produrrebbe uno stato inconsistente?
• Cosa dovresti mostrare in DevTools per dimostrare che ogni transizione aggiorna localStorage?
• Se il Registro permettesse guasto → disponibile direttamente dalla UI, quale funzione di dominio staresti aggirando?

Una risposta accettabile usa i nomi reali delle funzioni e degli stati del progetto.

Errori da evitare

• non aprire DevTools durante la verifica — il JSON è la prova della correttezza, non solo la UI;
• non testare il caso G3 (transizione non valida) prima della presentazione — è il test che dimostra che verificaTransizione funziona;
• lasciare che la UI permetta transizioni non valide attraverso pulsanti sempre visibili — i pulsanti delle azioni devono essere condizionati allo stato corrente;
• non documentare il comportamento per il caso G1 (guasto durante prestito) — durante la presentazione ti verrà chiesto;
• considerare completa la verifica dopo aver testato solo il percorso felice.

Prodotto da consegnare

Consegna la scheda di verifica compilata con:

• tutti i checkbox del percorso principale spuntati;
• tutti gli scenari G1-G4 verificati con esito documentato;
• una nota sul comportamento del caso G1 (guasto durante prestito) e G3 (transizione non valida).

Checklist di chiusura

Prima di chiudere la lezione, controlla:

• il ciclo completo disponibile → guasto → in_manutenzione → disponibile è stato verificato;
• ogni transizione è stata osservata in DevTools e nel JSON di localStorage;
• lo strumento guasto non compare nella lista dei prestabili;
• la transizione guasto → disponibile direttamente non è possibile dalla UI;
• tutti gli scenari G1-G4 sono stati eseguiti e documentati.

Risultato atteso

Alla fine lo studente deve saper dire:

Ho verificato il ciclo guasto nel Registro: disponibile → guasto → in_manutenzione → disponibile.
Ogni transizione aggiorna lo stato in localStorage, visibile in DevTools.
Lo strumento guasto non può essere prestato: il messaggio di errore è visibile.
La transizione guasto → disponibile senza manutenzione non è permessa.
Il comportamento del caso G1 (guasto durante prestito) è: [descrizione].

Se questa spiegazione non è possibile, la lezione non è ancora davvero conclusa.