Un generatore di indirizzi casuali sembra lo strumento più semplice di un kit di test e si comporta come uno dei più sottili. La casualità è utile proprio perché esplora combinazioni che nessuno ha pensato di annotare, ma un indirizzo non è un sacchetto di valori indipendenti — è una piccola rete di rapporti, e la casualità applicata a ciascun campo separatamente distrugge quei rapporti.
Questa guida spiega cosa dovrebbe essere casuale e cosa non deve mai esserlo, perché una chiave riproducibile conta più di un grande insieme di varianti, come l’esportazione in batch cambia la forma della vostra suite di test e quali errori multi-paese si ripresentano ancora e ancora. Alla fine saprete come ottenere varietà senza ottenere contraddizioni.
Perché casuale e incoerente sono problemi diversi?
Un indirizzo casuale non è la stessa cosa di un indirizzo arbitrario. La casualità vive nelle parti che non portano rapporti: il numero civico, il nome dell’edificio, la variante di ortografia esatta di una via, la sequenza dei record in un batch. Le parti deterministiche sono quelle che si vincolano a vicenda, e quelle dovrebbero essere derivate anziché estratte.
Considerate cosa succede quando ogni campo viene estratto in modo indipendente. La città è estratta da un elenco, la suddivisione amministrativa da un altro, il codice postale da un terzo e il prefisso telefonico da un quarto. Ogni singolo valore è valido, e la combinazione non lo è. Quattro valori validi producono un record non valido, e nessuna cura nella selezione di ciascun elenco lo impedisce.
La regola che risolve questo è l’ordine di generazione. Scegliete il paese, poi la suddivisione di primo livello, poi la località, poi derivate da quella catena il codice postale e il prefisso telefonico. La casualità viene quindi applicata solo dove non può contraddire nulla, il che vi dà varietà senza la classe di difetti di cui soffrono le fixture costruite a mano. L’articolo generatore di indirizzi statunitensi mostra lo stesso principio applicato all’interno di un singolo paese.
C’è un modo utile per descrivere la differenza. Un generatore di indirizzi casuali non estrae dodici campi; estrae una località e poi la descrive nel formato che quella località usa. Una volta che pensate al record come a un luogo prima e a un insieme di campi dopo, l’ordine di derivazione smette di essere un dettaglio tecnico e diventa il modo ovvio di costruire la cosa.
Cosa dovrebbe essere casuale e cosa dovrebbe essere fisso?
I valori che dovrebbero variare sono quelli che un modulo consuma come input opaco: nomi di vie all’interno di un insieme valido, numeri civici, designatori di unità, nomi di aziende, nomi di destinatari e l’ordinamento dei record in un’esportazione. Variare questi esercita il layout, i limiti di lunghezza e la gestione dei caratteri dei vostri campi, che è esattamente lo scopo di un generatore casuale.
I valori che dovrebbero essere fissi sono quelli con rapporti collegati. La suddivisione deve corrispondere alla località. Il codice postale deve corrispondere alla suddivisione. Il prefisso telefonico deve corrispondere alla regione. Il paese deve corrispondere al formato di ogni altro campo. Nessuno di questi può essere estratto in modo indipendente, e uno strumento che offre una modalità “completamente casuale” per uno di essi vi sta offrendo un difetto.
C’è una terza categoria che vale la pena nominare: valori che dovrebbero essere casuali in alcuni test e congelati in altri. Una data di nascita, per esempio, è utilmente casuale quando state cercando bug sui confini di età ed è dannosa quando state verificando una risposta specifica. La decisione appartiene al test, non al generatore, ed è per questo che un generatore che vi permette di fissare singoli campi è più utile di uno che offre solo un’unica modalità casuale.
Perché la riproducibilità batte la varietà
La stessa chiave e lo stesso paese dovrebbero produrre sempre lo stesso record. Questo suona come un limite alla casualità ed è di fatto la proprietà che rende i dati generati utilizzabili nei test automatizzati.
Un’asserzione confronta un valore osservato con uno atteso. Se l’input cambia tra le esecuzioni, il valore atteso deve cambiare con esso, e il test smette di verificare qualcosa sul comportamento e inizia a verificare che il generatore è imprevedibile. Quello è un test che può fallire solo per le ragioni sbagliate.
La riproducibilità rende anche riproducibili gli errori. Quando un test fallisce su un record generato, la prima domanda è cosa conteneva il record. Con una chiave potete rigenerarlo esattamente e ispezionarlo. Senza, il record è sparito, l’errore è irripetibile e la segnalazione di bug diventa un aneddoto.
È la proprietà attorno a cui è costruito il generatore di indirizzi su questo sito: una chiave, un paese, un record stabile e una chiave diversa ogni volta che ne volete uno diverso. È anche il motivo per cui un generatore che offre solo un pulsante di mescolamento è uno strumento più debole di quanto sembri a prima vista, perché un mescolamento non può essere ripetuto quando una build fallisce il mese prossimo e nessuno riesce a riprodurre i dati che l’hanno causato.
Lo schema pratico è usare una chiave stabile per fixture. Una chiave per la fixture che guida il percorso felice, un’altra per il record con un nome di via insolitamente lungo, un’altra ancora per il record il cui codice postale porta il suffisso esteso. Una chiave per fixture è meglio di una chiave per test, perché diversi test possono condividere lo stesso record e una modifica ad esso diventa un atto deliberato anziché un incidente. L’articolo dati di indirizzo nelle fixture di test descrive come organizzare quelle chiavi affinché una suite di test resti leggibile man mano che cresce.
In che modo l’esportazione in batch cambia la vostra suite di test
Un singolo indirizzo generato supporta un controllo manuale. Un batch di diecimila supporta un tipo di test completamente diverso, e il formato di esportazione conta più del conteggio. Un CSV con una riga per indirizzo e intestazioni di colonna stabili vi permette di guidare un ciclo di test basato sui dati, popolare un database di staging e confrontare conteggi e distribuzioni dopo una migrazione.
Due proprietà rendono utilizzabile un’esportazione. La prima è che la riga di intestazione nomina i campi come li nomina il vostro schema, così che la mappatura sia esplicita anziché presunta. La seconda è che ogni riga porta qualche marcatore che la identifica come dato generato, in una colonna dedicata o nel nome del file e nelle note del set di dati, così che un’esportazione smarrita non possa essere scambiata per un estratto di produzione.
I batch grandi fanno anche emergere problemi che quelli piccoli nascondono. Se esportate mille indirizzi per un paese e i codici postali si raggruppano in una manciata di valori, o l’elenco delle città si ripete dopo venti righe, il batch rivela un problema di copertura che un campione di dieci record non mostrerebbe mai. I difetti di distribuzione sono il tipo di difetto che appare solo in volume, che è un altro motivo per testare in volume.
Cosa si rompe per primo quando mescolate i paesi
La generazione multi-paese è dove vive la maggior parte dei difetti interessanti, perché i rapporti che valgono all’interno di un singolo paese non esistono oltre i confini. Il primo errore è la mancata corrispondenza tra codice postale e regione, dove un codice postale valido del paese sbagliato viene abbinato a una città valida, cosa che nessun validatore a campo singolo intercetterà mai.
Il secondo è il prefisso telefonico. Un numero che porta il prefisso di chiamata di un paese mentre l’indirizzo si trova in un altro è una mancata corrispondenza che una suite di test attenta dovrebbe segnalare, e il rapporto tra prefisso e località è documentato nell’articolo corrispondenza tra prefisso telefonico e località. Il terzo è il problema dell’insieme di campi: i paesi non condividono uno schema, quindi un record generato per un paese che non ha codice postale produrrà un campo vuoto dove il vostro test si aspettava cinque cifre.
Il quarto errore è più sottile e deriva dal modulo anziché dai dati. Se il vostro template di indirizzo insiste su un campo stato per ogni paese, allora ogni record generato porterà un valore di stato che nella maggior parte di essi non significa nulla. L’articolo formato di indirizzo internazionale spiega come gli insiemi di campi differiscono da paese a paese e perché un template universale è un compromesso anziché una soluzione.
C’è un quinto errore che appare solo quando i record vengono confrontati tra loro. Un batch che mescola paesi non si ordinerà correttamente con una sola collazione, perché le lettere di una lingua si ordinano diversamente dalle lettere di un’altra. Un elenco che sembra in disordine di solito non è affatto in disordine; è stato ordinato con le regole sbagliate, e la correzione appartiene al livello di visualizzazione anziché ai dati.
Gli indirizzi casuali sono utili per i test di carico?
Lo sono, con una condizione: il generatore di carico non deve passare più tempo a generare di quanto il sistema passi a servire. Un generatore che produce un record ben formato in tempo costante è adatto a una prova di carico, e uno che valida ogni record contro un servizio remoto non lo è.
Lo schema utile è generare un grande batch offline, memorizzarlo e far leggere al test di carico da quel batch anziché chiamare il generatore nel ciclo caldo. Questo rende anche riproducibile il test di carico, perché lo stesso batch viene riprodotto a ogni esecuzione e l’unica variabile rimasta è il sistema in prova.
Il fuzzing è il caso opposto. Lì volete input deliberatamente malformati, e un generatore che produce solo record validi non aiuterà. L’approccio produttivo è generare un record valido e poi mutarlo in modi controllati — troncare un campo, inserire un carattere fuori dall’insieme atteso, scambiare il codice postale con un valore di un altro paese — e registrare quale mutazione il sistema ha tollerato. Una mutazione che supera un controllo di formato ma rompe un processo a valle è un risultato che vale la pena avere. Tenete il catalogo delle mutazioni sotto controllo di versione insieme alle impostazioni del generatore, così che una mutazione che una volta ha causato un errore venga riprodotta a ogni esecuzione successiva.
Cosa non può essere un record casuale
Un indirizzo generato è un dato sintetico con struttura corretta e campi internamente coerenti. Non è una località consegnabile, non corrisponde ad alcun edificio e non è registrato ad alcuna persona o organizzazione. Non sarà accettato da un corriere e non può servire come prova di residenza.
Vale la pena affermare quel confine all’interno del set di dati stesso, non solo in un documento accanto ad esso. Una colonna che marca le righe come generate, un nome di file che lo dice e una nota nella fixture che descrive a cosa servono i dati rendono insieme un incidente molto meno probabile, e un incidente è il modo in cui i dati di test finiscono in un luogo dove non dovevano mai stare.
La casualità inoltre non rende anonimi i dati se i valori sono stati presi da persone reali. Estrarre un nome reale e un indirizzo reale da un record reale e mescolarli produce un problema di tipo diverso anziché uno risolto. L’unico record di test sicuro è quello che non è mai appartenuto a nessuno in partenza.
C’è un’ulteriore proprietà che vale la pena nominare, perché è facile perdere quando uno strumento viene giudicato sulla varietà del suo output. Un record casuale è comunque un record, e un record con uno scopo dovrebbe essere memorizzabile. Se non riuscite a scrivere l’indirizzo generato in un file, a salvarlo come fixture e a rigenerarlo sei mesi dopo da una nota, allora la casualità vi costa riproducibilità senza comprarvi nulla che non avreste potuto ottenere da un campione fisso più grande.
Ogni record prodotto in questo modo esiste per testare il software, e nient’altro. Non deve essere usato per impersonare qualcuno, per aprire o registrare conti reali, per ricevere posta effettiva, per dimostrare un indirizzo o un’identità, o per superare qualsiasi fase di verifica.