Generatore di indirizzi falsi: crea indirizzi di test validi (2026)

Ogni risultato è assemblato da una definizione di paese, una delle cinque fixture di città di quel paese, un elenco di nomi di strade, un numero civico e un pattern di codice postale. Il generatore sceglie un paese, sceglie una fixture di città al suo interno, costruisce una riga stradale nell'ordine locale e compila il codice postale dal pattern. Nulla viene campionato da un database di consegne e nulla viene copiato da una casella postale reale.

Questo offre due garanzie e due non-garanzie. Garantito: il formato segue le convenzioni del paese e lo stesso seed restituisce lo stesso indirizzo. Non garantito: che la strada esista a quel numero, o che un codice postale non statunitense corrisponda a una zona di consegna reale. Per i ZIP statunitensi esiste un controllo di esistenza separato su un dataset di 40.979 righe nel verificatore di codici postali. Al di fuori degli Stati Uniti il controllo è solo strutturale, e il sito lo dichiara invece di lasciar intendere altro.

I moduli di indirizzo raramente testano l'indirizzo. Testano il livello di validazione, il masking, i limiti di lunghezza, la dipendenza paese-regione e il serializzatore che scrive la riga nel database. Un fixture già malformato nasconde tutto questo. Se il tuo fixture canadese è "123 Main St, Toronto, ON 12345", il modulo accetta un pattern che un codice postale canadese reale non può mai rispettare, e il bug arriva in produzione.

Il fallimento opposto è altrettanto comune. I team scrivono a mano un fixture dall'aspetto reale ma sbagliato per il paese, poi aggiungono una soluzione nel validatore per accettarlo. Sei mesi dopo quella soluzione è portante e nessuno ricorda perché il campo del codice postale tedesco accetti lettere. I dati generati che seguono i pattern pubblicati eliminano entrambe le direzioni di deriva, purché il generatore stesso sia onesto su ciò che sa.

Gli indirizzi sintetici appartengono a ogni livello sotto la produzione: unit test per parser e validatori, test di integrazione che scrivono e leggono righe di indirizzo, test end-to-end che compilano un modulo di checkout, test di carico che necessitano volume senza toccare un cliente reale e esecuzioni di screenshot localizzate per una pagina di marketing. Sono utili anche per il fuzzing, perché puoi generare deliberatamente valori al limite di un limite di lunghezza o di un set di caratteri.

Sono lo strumento sbagliato per qualsiasi cosa dipenda da un punto di consegna reale. Non usarli per controlli antifrode, verifica dell'identità, elusione di ban, creazione di account, manipolazione di recensioni o test end-to-end di un'integrazione di spedizione. Un indirizzo sintetico non ha una casella postale, quindi qualsiasi passaggio che richieda una scansione reale del corriere fallirà, e usare identità generate per ottenere beni o servizi è frode indipendentemente da come sono stati prodotti i dati.

Il generatore copre 38 paesi. Ogni paese porta cinque fixture di città, quindi ci sono 190 definizioni di città in totale, e ogni città conosce il proprio codice di regione, il proprio pattern postale e le convenzioni stradali locali. La copertura è ponderata verso i mercati in cui i moduli di indirizzo vengono effettivamente costruiti: Nord America, Europa occidentale e settentrionale e i maggiori mercati dell'Asia-Pacifico e dell'America Latina.

Due paesi del set non hanno alcun codice postale: Hong Kong e gli Emirati Arabi Uniti. Il generatore lascia il campo vuoto per entrambi invece di inventare un numero. Questo è il comportamento corretto. Un modulo che contrassegna il codice postale come obbligatorio in quei paesi è rotto, e un fixture che fornisce un codice falso nasconderà il difetto finché un utente reale non lo incontra.

Un generatore è valido quanto la sua tabella dei paesi. I pattern seguenti sono quelli che più spesso vengono appiattiti in un unico modello a forma di US. Nota che il Giappone inverte completamente l'ordine, che i Paesi Bassi mettono lettere dopo le cifre e che Brasile e Giappone usano entrambi un trattino convenzionale anziché strutturale.

I codici postali devono essere memorizzati come stringhe. Germania, Francia, Spagna, Italia e Polonia emettono tutti codici con zeri iniziali, e una colonna intera trasforma silenziosamente 01067 in 1067. Lo stesso vale per i codici australiani e brasiliani. Se il tuo schema ha una colonna postale numerica, il fixture la esporrà nel momento in cui esegui il seed di un indirizzo tedesco.

Un generatore che restituisce un indirizzo diverso a ogni chiamata non è un fixture, è rumore. La generazione con seed fissa un input in modo che la sequenza di output sia stabile tra macchine e tra esecuzioni. Passa il seed esplicitamente nei test, registralo con qualsiasi dataset generato e tratta un cambio di seed come un cambio di fixture che richiede revisione.

Il pattern pratico è derivare seed per entità da un seed padre, ad esempio un hash del seed e dell'indice del record. Questo mantiene stabile il dataset producendo comunque valori diversi per riga. Rende anche riproducibili i fallimenti: quando la CI segnala un indirizzo errato, il seed più l'indice bastano a rigenerare esattamente quella riga. Non derivare mai il seed dall'orologio o da una chiamata casuale, perché è così che un test instabile diventa un mistero permanente.

Sono due affermazioni diverse e confonderle è il modo più comune in cui una suite di test mente ai suoi proprietari. Un controllo strutturale risponde a "questa stringa corrisponde al pattern del paese". Un controllo di esistenza risponde a "questo codice appare in un dataset di riferimento". Il verificatore di codici postali su questo sito fa il primo per ogni paese e il secondo solo per i ZIP statunitensi, dove consulta 40.979 righe.

Un passaggio strutturale ti dice che il modulo non rifiuterà un valore ben formato. Non ti dice nulla su se un corriere può consegnarlo, se il numero civico è nel range per quella strada o se la città corrisponde allo ZIP. Questi richiedono dati di riferimento postali che questo sito non fornisce. Scrivi le tue asserzioni in modo che corrispondano al controllo che esegui effettivamente, altrimenti i nomi dei test prometteranno troppo per anni.

Il sito non genera numeri di previdenza sociale, numeri di carte di pagamento, valori IMEI o IMSI, indirizzi Bluetooth o numeri di serie dei dispositivi. È un confine deliberato, non una funzionalità mancante. Quegli identificatori portano checksum, registri di allocazione o restrizioni legali, e un valore generato dall'aspetto plausibile è molto più pericoloso di uno ovviamente falso perché può superare un validatore ingenuo e finire in uno screenshot, in un ticket o in un commit.

Lo stesso confine vale per i dati di contatto. Gli indirizzi email generati usano sempre il dominio riservato example.test, che non può mai risolvere a una casella postale reale. I numeri di telefono generati sono limitati al blocco NANP 555-0100 fino a 555-0199 negli Stati Uniti e in Canada, l'intervallo riservato all'uso fittizio. Se un flusso di lavoro richiede un numero di carta o un identificativo fiscale, usa i valori di test ufficiali pubblicati dal processore o dall'autorità fiscale, e mai un valore estratto da un generatore.