Esercizio: scrivere un caso d’uso senza UI

Questa lezione e un esercizio pratico.

Devi scrivere o completare un caso d’uso senza usare la UI.

Questo e il controllo piu semplice per capire se l’architettura sta migliorando:

Posso eseguire l'operazione senza browser e senza click?

Se la risposta e si, il caso d’uso e separato dalla presentation.

Obiettivo

Scrivere un piccolo script che:

• crea archivi in memoria;
• prepara dati iniziali;
• crea un caso d’uso;
• lo chiama con un comando;
• controlla il risultato;
• non usa document, form o bottoni.

Scegli il caso d’uso

Puoi scegliere uno di questi:

• RegistraStrumento;
• CercaStrumenti;
• RegistraPrestito;
• ChiudiPrestito;
• ApriSegnalazioneGuasto.

Consiglio:

Se vuoi un esercizio semplice, scegli RegistraStrumento.
Se vuoi vedere il coordinamento vero, scegli RegistraPrestito.

Struttura dello script

Crea un file di prova manuale:

src/playground/provaCasoUso.js

Oppure usa un file temporaneo durante la lezione.

Esempio:

import { creaArchivioStrumentiInMemoria } from "../infrastructure/archivioStrumentiInMemoria.js";
import { creaRegistraStrumento } from "../application/registraStrumento.js";

const archivioStrumenti = creaArchivioStrumentiInMemoria();

const registraStrumento = creaRegistraStrumento({
  archivioStrumenti,
});

const risultato = registraStrumento({
  id: "s-001",
  nome: "Arduino Uno",
  categoria: "microcontrollori",
  stato: "disponibile",
});

console.log(risultato);
console.log(archivioStrumenti.tutti());

Questo non e ancora un test automatico, ma e una verifica utile.

Esercizio base: RegistraStrumento

Completa:

const risultato = registraStrumento({
  id: "s-001",
  nome: "Arduino Uno",
  categoria: "microcontrollori",
  stato: "disponibile",
});

Poi verifica:

Il risultato ha nome Arduino Uno.
L'archivio contiene uno strumento.
Lo stato e disponibile.

Poi prova un caso non valido:

registraStrumento({
  id: "s-002",
  nome: "",
  categoria: "misura",
  stato: "disponibile",
});

Errore atteso:

NOME_STRUMENTO_OBBLIGATORIO

Esercizio intermedio: RegistraPrestito

Prepara:

archivioStrumenti.salva({
  id: "s-001",
  nome: "Kit sensori",
  categoria: "robotica",
  stato: "disponibile",
});

Poi:

const risultato = registraPrestito({
  prestitoId: "p-001",
  strumentoId: "s-001",
  assegnatario: "Sara 3B",
  apertoIl: "2026-05-09",
});

Controlla:

Il prestito e aperto.
Lo strumento e in_prestito.
L'archivio prestiti contiene un prestito.
L'archivio strumenti contiene lo strumento aggiornato.

Poi prova:

registrare un prestito per uno strumento guasto

Errore atteso:

STRUMENTO_NON_PRESTABILE

Non usare la UI

Durante l’esercizio sono vietati:

document.querySelector(...)
addEventListener(...)
innerHTML
textContent
localStorage

Perche?

Perche qui stai controllando il caso d’uso, non l’interfaccia.

La UI verra collegata dopo.

Scheda di verifica

Compila:

# Verifica caso d'uso senza UI

Caso d'uso scelto:

Comando usato:

Dati iniziali:

Risultato atteso:

Risultato ottenuto:

Errore provato:

Che cosa ho verificato senza usare la UI:

Da esercizio manuale a test

Quello che fai qui puo diventare un test automatico.

Esempio manuale:

const risultato = registraStrumento(comando);
console.log(risultato.nome);

Test futuro:

expect(risultato.nome).toBe("Arduino Uno");

Il modulo sui test riprendera proprio questi scenari.

Cosa produrre

Alla fine della lezione devi avere:

• uno script o una scheda di verifica;
• un caso d’uso chiamato senza UI;
• almeno uno scenario valido;
• almeno uno scenario di errore;
• una lista di dettagli UI che non hai usato;
• una nota su come trasformare la verifica in test.

Spiegazione guidata per studiare

Questa lezione va studiata su due piani. Il primo è il comportamento visibile del Registro del laboratorio: che cosa vede o fa l’utente quando registra uno strumento, cerca un dispositivo, apre un prestito o segnala un guasto. Il secondo è il confine architetturale: dove deve stare il codice che rende possibile quel comportamento.

Per esercizio: scrivere un caso d’uso senza UI, il punto centrale è questo: Un caso d’uso coordina un’operazione completa: riceve un comando, legge ciò che serve, applica regole, salva il risultato e restituisce un esito.

Il rischio tipico è far diventare il caso d’uso una seconda UI o un secondo database. Deve coordinare, non mostrare HTML e non conoscere dettagli tecnici di salvataggio. Per evitarlo, non partire dal file che hai già aperto nell’editor. Parti dalla domanda: “quale responsabilità sto modificando?”. Se la risposta riguarda una regola del laboratorio, guarda il dominio. Se riguarda una sequenza di operazioni, guarda i casi d’uso. Se riguarda salvataggio, file, localStorage, API o database, guarda l’infrastruttura. Se riguarda input, pulsanti, form e messaggi, guarda la Presentation.

Il tempo è sufficiente per alternare spiegazione, modifica guidata e revisione. Alla fine della lezione lo studente non deve ricordare una definizione a memoria: deve saper indicare un punto del progetto, spiegare perché quel codice sta lì e mostrare una verifica del comportamento.

Passo per passo nel progetto

1. Rileggi il titolo della lezione e riscrivilo come domanda pratica. Per esempio: “dove deve stare questa regola?”, “chi deve salvare questo dato?”, “come verifico questo errore?”.
2. Apri solo i file necessari. Se devi toccare più di tre file, fermati e scrivi prima una mini-mappa.
3. Definisci input e output del caso d’uso.
4. Leggi i dati attraverso un archivio o una dipendenza esplicita.
5. Chiama le regole del dominio.
6. Salva il risultato senza sapere come funziona la persistenza concreta.
7. Aggiorna una nota breve nel README o negli appunti se hai cambiato un confine del progetto.

Esempio da leggere lentamente

Questo esempio serve a ragionare, non a incollare codice senza capire:

function registraPrestito(comando, archivioStrumenti, archivioPrestiti) {
  const strumento = archivioStrumenti.trovaPerId(comando.strumentoId);
  verificaStrumentoPrestabile(strumento);
  const prestito = apriPrestito(strumento.id, comando.nomePersona);
  archivioPrestiti.salva(prestito);
  archivioStrumenti.salva({ ...strumento, stato: "in_prestito" });
  return prestito;
}

Leggilo chiedendoti che cosa cambierebbe se domani sostituissimo la pagina web con una CLI, oppure localStorage con un’API. Se l’esempio continua ad avere senso senza riscrivere tutto, il confine è probabilmente buono. Se invece un dettaglio tecnico si propaga in molti file, il progetto sta tornando fragile.

Prova di comprensione

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

• Qual è la responsabilità principale trattata in questa lezione?
• In quale livello del progetto dovrebbe stare?
• Quale errore faresti se cercassi la soluzione più veloce?
• Quale piccolo test, controllo manuale o esempio dimostra che hai capito?
• Che cosa deve restare facile da cambiare dopo questa lezione?

Una risposta accettabile non deve essere lunga. Deve però usare parole concrete del Registro: strumento, prestito, stato, archivio, caso d’uso, messaggio, test.

Controllo finale

La lezione e completata quando puoi rispondere si:

• ho chiamato un caso d’uso senza bottone;
• ho preparato dati iniziali in modo esplicito;
• ho controllato il risultato;
• ho provocato almeno un errore;
• il caso d’uso non dipende da document;
• so come questo esercizio diventera un test.

Nella prossima lezione chiudiamo il modulo con una checklist.