Lo sviluppo frontend spesso inizia prima che il backend sia pronto a fornire dati reali. Invece di aspettare un'API funzionante, si possono generare dati JSON di test realistici nella forma giusta e iniziare subito a lavorare.
Cosa sono i dati fittizi
Un JSON "mock" è composto da dati generati ma strutturalmente plausibili: nomi che sembrano nomi veri, date nel formato corretto, identificatori con l'aspetto giusto. A differenza di valori segnaposto come "test123", i mock realistici mostrano subito se l'interfaccia gestisce correttamente nomi lunghi, campi vuoti o formati di data specifici.
A cosa serve
- Iniziare a sviluppare l'interfaccia prima che il team backend finisca l'API.
- Testare come si comporta l'interfaccia con un gran numero di record, senza dover popolare un database reale.
- Creare una demo o un prototipo senza esporre dati reali degli utenti.
- Scrivere test automatici che non dipendano dallo stato di un servizio esterno o di un database.
Il Codice Fiscale è un campo mock a parte
Un indirizzo italiano mette il numero civico dopo il nome della via ("Via Roma 12"), con un CAP di 5 cifre prima della città, senza trattini. Ma la vera trappola per un generatore di mock è il Codice Fiscale: un identificatore alfanumerico di 16 caratteri calcolato da nome, cognome, data e luogo di nascita, con un carattere di controllo finale. Un template che genera semplicemente 16 lettere e cifre casuali produce un valore sintatticamente plausibile, ma qualunque validazione reale del Codice Fiscale — anche solo un controllo di formato — lo respingerebbe subito come non valido.
A cosa prestare attenzione
I dati fittizi riproducono bene la forma e i tipi dei dati reali, ma non la logica di business o le relazioni tra i record. Prima di andare in produzione il codice va comunque testato con un'API reale — i mock servono solo ad accelerare le prime fasi dello sviluppo.
Edge case realistici nei mock
Un buon generatore di mock include deliberatamente valori "scomodi" — nomi molto lunghi, stringhe vuote, caratteri accentati (à, è, ò) e Unicode, numeri nulli o negativi, date al limite dell'intervallo. Sono proprio questi valori a rompere più spesso l'interfaccia o la logica che uno sviluppatore ha testato solo con dati "comodi" come "John Doe" — per questo la casualità dei mock è più utile che avere sempre lo stesso identico esempio di test.