Un generatore di indirizzi statunitensi vi fornisce indirizzi americani completi su richiesta, assemblati a partire da un numero civico, un nome di via, un’unità opzionale, una città, un’abbreviazione di stato di due lettere e un codice ZIP di cinque cifre che può portare un’estensione di quattro cifre. Ciò che distingue un generatore utile da un semplice costruttore di stringhe casuali è che ogni campo concorda con gli altri: la città appartiene allo stato, e il codice ZIP appartiene a entrambi.
Questa guida illustra da cosa è fatto realmente un indirizzo statunitense, come si rapportano tra loro gli stati, i territori e le suddivisioni, perché la coerenza tra il codice ZIP e la città conta più di quanto la maggior parte dei team si aspetti, e dove si colloca il confine onesto dei record generati. Alla fine saprete quali difetti di un indirizzo i vostri moduli dovrebbero intercettare, e quali invece un generatore rimuove silenziosamente per voi.
Da cosa è fatto realmente un indirizzo degli Stati Uniti?
Un indirizzo americano si scrive dal più piccolo al più grande, cioè all’opposto dell’ordine usato in Giappone e in diversi altri sistemi postali. La riga del destinatario viene per prima, poi il numero civico e il nome della via, poi l’unità o l’appartamento, poi la città, poi l’abbreviazione dello stato, poi il codice ZIP. Quando l’indirizzo viene scritto su una sola riga, la forma standard mette insieme città e stato, una virgola e il codice ZIP alla fine. Un generatore di indirizzi statunitensi che rispetta questa sequenza produce un’etichetta che si legge correttamente per un corriere, mentre uno che riordina gli elementi produce una riga che sembra straniera anche quando ogni valore al suo interno è corretto.
L’elemento dello stato è sempre un codice di due lettere anziché un nome per esteso, e il servizio postale mantiene quell’elenco come un insieme fisso. Il codice ZIP è di cinque cifre e, dalla fine degli anni Ottanta, può essere seguito da un suffisso opzionale di quattro cifre dopo un trattino per identificare un segmento di consegna più piccolo. I moduli che accettano la forma estesa devono accettare entrambe le lunghezze, perché un set di dati che porta sempre e solo la versione a cinque cifre non eserciterà mai il percorso più lungo.
L’unità è il campo che più probabilmente è opzionale in un sistema e obbligatorio in un altro. Un appartamento, un interno, un piano, un’unità o un numero di edificio possono essere scritti come una parola seguita da un numero, come un simbolo di cancelletto seguito da un numero, oppure come un semplice numero su una seconda riga. Ognuna di queste forme arriva nei dati reali, quindi un parser che gestisce solo la forma con la parola rifiuterà input validi.
In che modo differiscono gli stati, il Distretto di Columbia e i territori
Cinquanta stati, il Distretto di Columbia e i territori abitati hanno tutti i propri codici di due lettere, e non sono intercambiabili in un menu a tendina. Il Distretto di Columbia porta il codice DC e per finalità di indirizzo si comporta come uno stato, ma non lo è, e i sistemi che modellano il primo livello della gerarchia come “stato” lo etichettano in modo errato nei report e nei filtri.
I territori sono il problema più silenzioso. Porto Rico porta PR, Guam porta GU, le Isole Vergini degli Stati Uniti portano VI, le Samoa Americane portano AS e le Isole Marianne Settentrionali portano MP. Alcuni sistemi di spedizione e fiscali li trattano come destinazioni nazionali, altri come internazionali, il che significa che un modulo che codifica rigidamente “US” come unico paese accettabile insieme a un codice di territorio produrrà una combinazione che il resto dello stack rifiuta.
Esiste anche un gruppo di stati liberamente associati e di aree periferiche minori che compaiono nei set di dati di riferimento con i propri codici ma raramente compaiono su un’etichetta di spedizione. Un generatore che dichiara copertura americana dovrebbe essere esplicito sul fatto che includa solo i cinquanta stati, oppure gli stati più DC, oppure l’insieme completo con i territori. La differenza conta quando state testando un menu a tendina di giurisdizioni anziché un campo indirizzo stradale.
Perché il codice ZIP, la città e lo stato devono muoversi insieme
Il difetto più comune nei dati di indirizzo americani costruiti a mano è una mancata corrispondenza tra il codice ZIP e il luogo a cui dovrebbe appartenere. Qualcuno seleziona un nome di città plausibile, digita un numero plausibile di cinque cifre, e i due non hanno alcun rapporto tra loro. Niente di ciascun valore sembra sbagliato preso isolatamente, ed è esattamente per questo che il difetto sopravvive alla revisione e raggiunge una fixture.
La selezione casuale indipendente peggiora la situazione anziché migliorarla. Se estraete una città da un elenco di mille nomi e un codice ZIP da un intervallo di quarantamila possibilità, la probabilità che la coppia sia autentica è trascurabile. È lo stesso errore che si presenta in ogni altro paese, che si tratti di un distretto turco abbinato alla provincia sbagliata o di un codice postale brasiliano associato al comune errato.
La soluzione è strutturale anziché redazionale. Decidete prima lo stato, poi scegliete una città e un codice postale che appartengano entrambi ad esso, e ricavate il prefisso telefonico dalla stessa regione. Un generatore che lavora in questo ordine non può produrre una coppia interregionale, ed è per questo che il generatore di indirizzi su questo sito costruisce ogni record partendo da un’unica regione verso il basso. Il rapporto più ampio tra i campi è discusso nell’articolo coerenza dei campi, e si applica altrettanto direttamente alle colonne degli indirizzi quanto alle colonne dell’identità.
Cosa significa realmente la copertura dietro un generatore di indirizzi statunitensi?
Le cifre sulla copertura sono facili da gonfiare e difficili da interpretare, quindi è utile sapere a cosa si riferiscono i conteggi. Su questo sito, il set di dati americano copre l’insieme completo delle suddivisioni di primo livello, circa duecento località abitate, poco meno di duemila suddivisioni amministrative sotto di esse e oltre tredicimila codici postali tratti dall’assegnazione reale.
Quei numeri contano meno dei rapporti tra loro. Duecento città contro tredicimila codici ZIP significa che il luogo medio ha molti codici postali, e un generatore che campiona l’elenco delle città e l’elenco degli ZIP in modo indipendente produrrà comunque mancate corrispondenze la maggior parte delle volte. L’affermazione significativa non è quanti valori esistono, ma che una città scelta arrivi sempre con un codice postale che le appartiene. Uno strumento in grado di produrre una coppia corretta da due elenchi qualsiasi vale più di uno che contiene un elenco più lungo di valori non collegati, perché solo il primo può essere usato dentro un’asserzione che reggerà ancora l’anno prossimo.
Vale anche la pena sapere a cosa servono le suddivisioni sotto il livello della città. In molti paesi il livello intermedio è l’unità a cui si agganciano i codici postali, ed è per questo che i set di dati sono organizzati gerarchicamente anziché come elenchi piatti. Un modulo di indirizzo che chiede sempre e solo città, stato e ZIP sta scartando uno strato che altri paesi richiederanno, e una suite di test che non esercita mai quello strato non rivelerà la differenza.
Quali difetti degli indirizzi dovrebbero intercettare i vostri moduli
I dati generati sono utili per confermare che un modulo accetta input corretti, e ancora più utili per confermare che rifiuta input scorretti. I difetti per cui vale la pena scrivere casi sono quelli che un modulo può effettivamente rilevare: un codice ZIP troppo corto o troppo lungo, un codice di stato che non è nell’elenco, una città che non corrisponde allo stato selezionato, un’unità più lunga di quanto il campo consenta, e una riga stradale che supera la larghezza della colonna memorizzata.
Poi ci sono i casi che un modulo non può rilevare e che quindi non dovrebbe pretendere di rilevare. Un codice ZIP formattato correttamente ma appartenente a una città diversa da quella inserita non è qualcosa che la validazione lato client possa risolvere, e nemmeno un nome di città scritto diversamente da quello ufficiale. Trattare questi casi come errori di validazione produce falsi rifiuti, un esito peggiore dell’accettare un record leggermente strano.
Un file di test produttivo per i flussi di checkout di solito contiene una serie di record di indirizzi statunitensi generati per il percorso felice, un piccolo insieme di valori deliberatamente malformati per il percorso di rifiuto, e uno o due record con forme insolite ma legali come un codice di territorio, un codice ZIP esteso e un nome di via che porta un punto o un apostrofo. L’articolo casi di test per il modulo indirizzo di checkout ne elenca altri, e il pezzo sul formato di indirizzo internazionale spiega perché lo stesso campo può essere obbligatorio in un paese e assente in un altro. Dove un campo rifiuta un valore, verificate sia il messaggio sia il rifiuto, perché un messaggio chiaro e uno generico falliscono con gli utenti in modi molto diversi.
Gli indirizzi americani generati sono consegnabili?
No, e nessuno strumento onesto dovrebbe suggerire il contrario. Un indirizzo generato ha la struttura corretta e i rapporti interni corretti, che è ciò di cui un parser di moduli, un insieme di regole di validazione o un flusso di checkout ha bisogno per essere esercitato. Non corrisponde a un edificio reale, non è registrato a nessuno e non sarà accettato da alcun corriere come destinazione.
Questa distinzione è facile da confondere quando i dati sembrano ordinari. Il numero civico è plausibile, il nome della via è un nome di via reale usato da qualche parte nel paese, e la città esiste davvero. È la combinazione a renderlo sintetico, perché quella particolare casa su quella particolare via non corrisponde al record che avete davanti.
La conseguenza pratica è una regola che appartiene alle note del set di dati anziché a un commento che nessuno legge: questi record esistono per testare il software, non devono essere usati per spedizioni reali e non devono essere presentati come il luogo di residenza di qualcuno. Se uno screenshot di dati di staging sfugge a un ambiente, il record dovrebbe dichiarare che cosa è.
Come dovreste memorizzare il risultato per riutilizzarlo in seguito
Memorizzate gli indirizzi generati come fixture una volta che hanno uno scopo, e conservate i parametri di generazione insieme ad essi. Una fixture che registra la chiave di identità, il paese e il seme usato per produrla può essere rigenerata anni dopo, ed è ciò che rende un vecchio test di regressione significativo anziché misterioso. L’articolo dati di indirizzo nelle fixture di test copre la meccanica.
Tenete le colonne dell’indirizzo separate da tutto il resto. Nomi dei destinatari, note interne, dettagli del fornitore e istruzioni di consegna non appartengono alla riga stradale, perché mescolarli ne gonfia la lunghezza, rompe i controlli sui caratteri e produce errori che sembrano problemi di indirizzo quando il vero difetto è uno schema che ha lasciato passare testo non correlato.
Infine, verificate i rapporti invece di fidarvi di essi. Un test che controlla che la città appartenga allo stato, e che il codice ZIP appartenga allo stesso stato, intercetta la maggior parte dei dati di indirizzo americani fatti a mano prima che raggiungano una fixture condivisa. Quella singola asserzione fa più per la qualità dei dati di quanta cura si possa mettere digitando i record a mano.
Mantenete accanto ad essa un’ulteriore abitudine. Quando un record fallisce un controllo di rapporto, correggete il generatore anziché il record, perché una riga corretta a mano è una riga che verrà sovrascritta la prossima volta che la fixture verrà aggiornata. Un controllo che nessuno può soddisfare modificando un singolo campo è un controllo che continua a funzionare.
Ogni indirizzo prodotto in questo modo è un dato di test sintetico con struttura corretta e rapporti interni corretti, e nient’altro. Non è una località consegnabile, non appartiene a nessuna persona o organizzazione, e non deve essere usato per impersonare qualcuno, per dimostrare una residenza, per ricevere posta reale o per superare una fase di verifica.