I dati di identità di test sono una persona inventata, scritta per intero. Sono un nome, un indirizzo, una data di nascita, un numero di identificazione governativo, un numero di telefono e una manciata di campi più piccoli, messi insieme affinché il software possa essere esercitato su un record che sembra ordinario senza descrivere nessuno che esista.
Questa guida spiega da dove vengono tali record, quali situazioni li richiedono davvero, perché i dati di produzione sono un cattivo sostituto anche quando sono disponibili, e cosa garantisce — e cosa non garantisce — un generatore su questo sito riguardo al risultato.
Che cosa sono davvero i dati di identità di test
Togli il gergo e un record di identità di test non è altro che un insieme coerente di risposte alle domande che pone un modulo. Qualcuno ha un nome proprio e un cognome, vive a un indirizzo dentro una particolare regione, è nato in un particolare giorno e possiede qualunque numero di identificazione quella regione rilasci. Il record è coerente nel senso che le risposte concordano tra loro.
Ciò che lo rende dati di test anziché dati reali è la provenienza. Nulla in esso è stato copiato da un essere umano, e nulla in esso appartiene a un essere umano. Ha la forma di una persona affinché un sistema possa elaborarlo, e nessun referente al di fuori del test.
Questa distinzione conta più di quanto sembri. Un record può essere perfettamente formattato e completamente inventato allo stesso tempo, ed entrambe le proprietà sono il punto.
Quando un team ha davvero bisogno di record come questi?
Cinque situazioni ricorrono continuamente. Sembrano diverse ma condividono un unico requisito: il software deve ricevere un input plausibile mentre l’output finisce da qualche parte innocua.
| Situazione | Cosa va storto senza record generati |
|---|---|
| Test funzionale dei moduli | Le regole di validazione per lunghezza, set di caratteri e campi obbligatori non possono essere esercitate affatto |
| Dimostrazioni e screenshot | Il testo segnaposto, come una singola lettera ripetuta, fa sembrare il prodotto incompleto |
| Popolamento massivo e prove di carico | Un database ha bisogno di migliaia di righe prima che qualcuno possa misurare le prestazioni in modo onesto |
| Fixture di test automatizzate | Le asserzioni derivano quando lo stesso test produce un record leggermente diverso a ogni esecuzione |
| Prove di migrazione | Un passaggio tra ambienti non può essere provato su dati che non assomigliano alla forma reale |
Nessuna di queste è migliorata dai dettagli di persone reali, e diverse diventano più difficili quando vi si mescolano dettagli reali. Non è un punto morale; è un punto pratico su ciò di cui un test ha bisogno per essere utile.
Perché i dati di produzione sono il sostituto sbagliato
L’istinto di copiare una fetta di produzione in un ambiente inferiore è comprensibile. I dati reali hanno la distribuzione giusta, i casi limite giusti e il disordine giusto. Sono anche il tipo di dati più costoso da perdere, e gli ambienti inferiori sono esattamente il luogo dove i controlli di sicurezza sono più deboli.
Ne derivano due guasti. Il primo è normativo: un nome insieme a una data di nascita, a un numero di identificazione o a un dato di contatto è un dato personale, e spostarlo in un ambiente di sviluppo è un nuovo uso a cui nessuno ha acconsentito. Il secondo è operativo: la copia persiste nei backup, nei log delle query, negli screenshot allegati alle segnalazioni di bug e nei portatili di chiunque l’abbia mai ripristinata. L’organizzazione ora possiede molte più copie degli stessi record sensibili di quante ne avesse prima, in luoghi che nessuno sorveglia.
L’articolo sulle regole sulla privacy per i dati di test affronta la questione più in profondità, incluso il motivo per cui togliere i nomi da una tabella copiata non equivale a rendere la tabella anonima. La versione breve è che il record di test più sicuro è quello che non è mai appartenuto a nessuno.
Cosa contiene un record generato
Su questo sito, il generatore di identità e dati di test costruisce l’intero insieme in una volta, anziché un campo alla volta. Un record di solito porta una sezione personale con nomi, data di nascita e genere; una sezione indirizzo con via, città, divisione amministrativa e codice postale; i dati di contatto; e gli identificatori amministrativi che il paese scelto rilascia effettivamente.
Due proprietà meritano di essere comprese prima di fare affidamento sull’output. La prima è la coerenza interna: l’indirizzo appartiene al paese che hai selezionato, il numero di telefono porta il prefisso telefonico di quel paese e, dove l’identificatore nazionale di un paese ha una regola pubblicata di cifra di controllo, il numero generato la soddisfa. La seconda è la riproducibilità. L’output è guidato da una chiave di identità, e la stessa chiave con lo stesso paese produce esattamente lo stesso record — ed è ciò che rende un record generato utilizzabile dentro un test automatizzato e non soltanto dentro uno manuale.
Ogni record prodotto in questo modo è sintetico ed esiste solo per il test; non deve essere usato per impersonare una persona reale, e non è una credenziale che qualche autorità abbia rilasciato o accetterebbe.
I record generati devono sembrare reali?
Devono sembrare ordinari, che è un requisito più debole. Un record che sembra esotico è un record che testa la cosa sbagliata: se ogni cognome generato è di una sola sillaba o ogni nome di via è una frase segnaposto, il layout non viene mai messo sotto stress e la validazione non scatta mai. I dati generati si guadagnano il loro posto quando arrivano nella stessa forma dell’input reale che il sistema riceverà alla fine, comprese le forme scomode — nomi lunghi, nomi con diacritici, indirizzi scritti senza spazi, numeri con uno zero iniziale.
Sembrare ordinario non equivale a essere utilizzabile. Possedere un numero di identificazione dalla forma corretta non significa che appartenga a qualcuno, e non soddisferà un controllo che consulta l’autorità emittente, perché dietro non c’è alcun record da consultare.
Perché le stesse coppie di campi continuano a fallire i controlli di coerenza
I team che costruiscono i record di test a mano incappano ripetutamente negli stessi difetti, e sono quasi sempre difetti di relazione più che difetti di valore. La via è plausibile, la città è plausibile, il codice postale è plausibile — e i tre appartengono a paesi diversi.
Il motivo è che un record scritto a mano viene assemblato campo per campo, e ogni campo viene giudicato in isolamento da chi lo digita. La casualità fa la stessa cosa, ma in fretta: estrazioni indipendenti producono coppie impossibili molto più spesso di quanto suggerisca l’intuito. Un generatore lo evita decidendo prima il paese e la divisione amministrativa e derivando tutto il resto da quelle due scelte, ed è per questo che la questione della coerenza dei campi è in realtà una questione sull’ordine di generazione.
Per gli sviluppatori: di cosa è fatto un record di identità
Modella il record come campi con dipendenze, non come una riga piatta di colonne indipendenti. Nome e genere, data di nascita ed età, paese e prefisso telefonico, divisione e codice postale, paese e formato dell’identificatore: ogni coppia ha un membro che vincola l’altro, e uno schema che nasconde quella relazione lascerà entrare righe incoerenti.
Due abitudini a livello di campo prevengono la maggior parte dei danni. Non derivare mai l’età da un intero memorizzato quando è memorizzata anche la data di nascita — conserva la data e calcola l’età, altrimenti le due discordano nel momento in cui passa un anno. E dove un paese non rilascia un particolare identificatore, tratta il campo come legittimamente assente invece di riempirlo con una stringa dall’aspetto plausibile, perché un campo vuoto e un campo sbagliato falliscono in modi molto diversi.
Per le fixture, preferisci un record fisso a uno casuale fresco ogni volta che l’asserzione riguarda il comportamento anziché la varietà dell’input. Un test che asserisce su una risposta specifica deve sapere quale fosse l’input. Riserva la generazione casuale ai test che vanno a caccia di casi limite sconosciuti, e una volta che un simile test trova qualcosa, congela quel record come fixture in modo che la regressione resti bloccata. Qualunque cosa contenga la fixture, la nota nel file dovrebbe dirlo chiaramente: questi record sono sintetici, servono solo per i test software e non devono essere usati come identità di alcuno.
Passi successivi
Scegli un modulo nel tuo prodotto e compilalo con un record generato invece che con il testo segnaposto che probabilmente vi si trova. Poi prendi la stessa chiave di identità e genera di nuovo — se il secondo record differisce dal primo, stai guardando uno strumento che non può supportare asserzioni automatizzate, e l’approccio alle fixture con vitest descrive cosa chiedere invece.