Un modulo di indirizzo al checkout è il punto in cui ogni problema di indirizzo ha finalmente un costo. Un campo che respinge un inserimento legittimo, un cambio di paese che scarta in silenzio ciò che era stato digitato, una validazione che scatta mentre l’utente sta ancora digitando — ognuno di questi si trasforma in un ordine abbandonato, e nessuno è visibile in uno unit test che controlla solo se una stringa sia interpretabile.
I casi di test seguenti sono scritti rispetto al comportamento del modulo nel suo complesso anziché rispetto a una funzione di validazione. Coprono le transizioni: cambiare paese, tornare a un indirizzo salvato, incollare e terminare su un telefono. Le regole sui dati sottostanti da cui dipendono sono descritte in validazione e normalizzazione degli indirizzi.
I moduli sono quelli che gli utenti incontrano davvero
Prima dell’elenco, una nota sul perché questi casi specifici. I bug severi nei moduli di checkout riguardano raramente un’unica stringa non valida. Derivano dallo stato: il campo che era stato popolato per un paese e non svuotato per il successivo, l’etichetta che dice ancora “codice ZIP” dopo che il paese è cambiato, il messaggio di validazione che resta sullo schermo dopo che il valore è stato corretto.
Scrivi casi che attraversano il modulo come farebbe una persona e verifica ciò che l’utente può vedere: se l’ordine può essere completato, che cosa dicono le etichette dei campi, se l’errore è collegato al campo giusto.
Casi di test per campi obbligatori e facoltativi
Inizia dalla forma del modulo stesso. Nella maggior parte dei paesi il codice postale è obbligatorio; in alcuni non esiste e deve essere facoltativo. Un campo distretto o stato è essenziale in alcuni mercati e privo di senso in altri. Un modulo che contrassegna ogni campo come obbligatorio è inutilizzabile nei paesi che non li hanno, e un modulo che non ne contrassegna nessuno come obbligatorio accetterà un indirizzo vuoto.
Casi che vale la pena eseguire: con solo i campi obbligatori compilati; con ogni campo compilato; con i campi facoltativi lasciati vuoti di proposito; con i campi facoltativi popolati ma con soli spazi bianchi; e con un campo che esiste nello schema ma è nascosto per il paese selezionato. Quest’ultimo intercetta il difetto classico in cui un campo nascosto viene comunque validato, così il modulo rifiuta di inviare e non mostra alcun errore che l’utente possa raggiungere.
Testa anche end-to-end il paese senza codice postale. Dovrebbe essere possibile completare l’ordine, e la conferma non dovrebbe mostrare una riga del codice postale vuota.
Che cosa accade quando cambia il paese?
Questo è il test di maggior valore dell’elenco, perché il selettore del paese cambia il significato di ogni altro campo. Eseguilo in entrambe le direzioni: da un paese con codice postale a uno senza, e viceversa.
Verifica che il codice postale inserito sotto il primo paese non persista in silenzio sotto il secondo, che l’etichetta del campo cambi nel termine locale e che qualsiasi errore di validazione esistente venga cancellato o ricalcolato anziché lasciato collegato a un campo le cui regole sono cambiate. Verifica anche che l’elenco delle suddivisioni venga sostituito anziché filtrato, poiché un elenco filtrato può lasciare una selezione che non esiste nel nuovo paese.
Un caso correlato: seleziona il paese per ultimo. Alcune persone compilano prima l’indirizzo e impostano il paese dopo. Se la validazione viene eseguita a ogni pressione di tasto, vedranno errori per un formato che era corretto per un paese non ancora scelto.
| Situazione | Che cosa dovrebbe verificare il test |
|---|---|
| Paese cambiato, poi cambiato di nuovo | Il codice postale inserito sotto il primo paese non persiste in silenzio sotto il secondo |
| Etichetta del campo | L’etichetta cambia nel termine locale per il paese appena selezionato |
| Errore di validazione esistente | Viene cancellato o ricalcolato, anziché lasciato collegato a un campo le cui regole sono cambiate |
| Elenco delle suddivisioni | Viene sostituito anziché filtrato, così nessuna selezione obsoleta sopravvive |
Incollare e compilazione automatica funzionano ancora?
Gli utenti incollano. Incollano un intero blocco di indirizzo nella prima riga, incollano un codice postale copiato da un’altra scheda, incollano un numero di telefono con punteggiatura e prefisso internazionale. Accettano anche ciò che il browser offre di compilare automaticamente.
Testa ciascuno. Incollare un indirizzo completo nella riga della via dovrebbe essere gestito con garbo oppure lasciare il campo modificabile e intatto; non deve scatenare un errore di validazione che blocca l’invio senza una spiegazione visibile. Incollare un codice postale con spazi bianchi circostanti dovrebbe essere accettato dopo l’eliminazione degli spazi. La compilazione automatica dovrebbe popolare i campi che l’utente si aspetta e non dovrebbe sovrascrivere un paese o una suddivisione già scelti.
Poi testa l’incollaggio che arriva lentamente, carattere per carattere, come fanno alcuni strumenti di assistenza. Una validazione che scatta alla prima pressione di tasto e mostra “codice postale non valido” mentre il valore è ancora incompleto è un difetto reale, non un caso limite.
Testare su un telefono e con una connessione lenta
I layout mobili cambiano ciò che l’utente può raggiungere. Casi che vale la pena eseguire a larghezza ridotta: il selettore del paese si apre e può essere chiuso; la tastiera non copre il campo in cui si sta digitando né il pulsante di invio; l’elenco delle suddivisioni è ricercabile o scorrevole quando è lungo; e il messaggio di errore è visibile senza dover scorrere via dal campo.
Aggiungi una connessione lenta o interrotta. Invia l’ordine, interrompi la risposta, invia di nuovo. Il modulo non dovrebbe creare due ordini perché il pulsante è rimasto attivo, e non dovrebbe perdere l’indirizzo inserito quando la richiesta fallisce. Un percorso con indirizzo salvato merita lo stesso trattamento: modifica un indirizzo salvato, abbandona la modifica e conferma che l’originale sia intatto.
Per gli sviluppatori: che cosa verificare e che cosa seminare
Verifica gli esiti che l’utente può osservare — l’invio riesce, viene mostrata l’etichetta giusta, l’errore è collegato al campo che l’ha causato — anziché le chiamate di validazione interne. Questo mantiene i test significativi quando cambia la libreria di validazione.
Semina il modulo da una serie di fixture che includa un indirizzo pulito per ogni mercato che servi e le incongruenze deliberate descritte in dati di indirizzo nelle fixture di test. Mantieni i dati di seed deterministici così un caso fallito può essere riprodotto esattamente, e genera i campioni puliti anziché digitarli a mano, come fa il generatore di indirizzi.
Infine, contrassegna gli ordini di test come ordini di test nell’ambiente stesso. Un ordine di test che sembra identico a uno reale finirà prima o poi per essere evaso, e un indirizzo generato per un test non è un indirizzo recapitabile.
Passi successivi
Scegli per primo il caso del cambio di paese — esercita la maggior parte del codice condiviso con la minor configurazione — e aggiungi il percorso senza codice postale nella stessa sessione. Poi esegui l’elenco completo una volta a larghezza mobile con la rete limitata, perché quella combinazione trova più difetti di checkout di qualsiasi quantità di validazione degli input aggiuntiva. Per le regole a livello di campo alla base di questi casi, inizia dalla struttura degli indirizzi statunitensi.