Il test della verifica email è la parte di un flusso di registrazione che la maggior parte dei team prova una volta, sul percorso felice, e poi dichiara finita. I guasti interessanti sono altrove: un link aperto due volte, un link aperto su un altro browser, un codice che arriva dopo che l’utente è già stato verificato, un messaggio che non arriva affatto. Questo articolo percorre gli stati che un flusso di verifica ha davvero e i casi che vale la pena coprire in ciascuno di essi.
Gli stati attraverso cui passa un flusso di verifica
Prima di scrivere un test, annota gli stati. Un flusso descritto come verificato o non verificato nasconde almeno quattro situazioni distinte, e ciascuna ha il proprio comportamento corretto.
| Stato | Cosa crede il sistema | Cosa può fare l’utente |
|---|---|---|
| Non verificato, nessun messaggio inviato | L’account esiste ma non è provato | Chiedere un altro messaggio |
| Non verificato, messaggio in viaggio | Esiste un token con una durata | Aspettare o chiedere di nuovo |
| Verificato | L’indirizzo è stato provato da un token valido | Usare l’account normalmente |
| Cambio in sospeso | Un nuovo indirizzo è proposto, il vecchio è ancora valido | Confermare o annullare |
La maggior parte dei difetti vive nelle transizioni, non negli stati. Chiediti cosa succede quando un utente chiede un secondo messaggio mentre il primo è ancora in viaggio, o conferma il nuovo indirizzo mentre è ancora connesso con quello vecchio.
Cosa si rompe quando un link di conferma viene aperto due volte?
Niente dovrebbe, ed è esattamente per questo che vale la pena testarlo. Un link di conferma viene consegnato attraverso un canale che l’utente non controlla del tutto: i client di posta ne mostrano l’anteprima, gli scanner di sicurezza li seguono e gli utenti ci cliccano una seconda volta per impazienza.
Il comportamento che vuoi è che il primo uso valido consumi il flusso e ogni uso successivo produca un esito chiaro e innocuo — una pagina di già verificato, o una richiesta di accesso — invece di un errore che l’utente non riesce a interpretare. Ciò che non vuoi è un secondo evento di verifica che reimposti una password, riemetta una sessione o fallisca con un messaggio che suggerisce che l’account sia rotto.
C’è un caso correlato che coglie i team alla sprovvista: due account, un indirizzo. Se il tuo prodotto consente lo stesso indirizzo su due account, un singolo messaggio di conferma non deve poter verificare entrambi. Testalo di proposito.
Testare i percorsi di cambio email e ripristino
Cambiare un indirizzo e reimpostare una password riusano lo stesso macchinario con una conseguenza diversa, ed è lì che un’implementazione condivisa inizia a perdere.
Quando un utente cambia un indirizzo, entrambi gli indirizzi esistono per un po’. Quello vecchio dovrebbe poter ancora recuperare l’account, e quello nuovo non dovrebbe avere effetto finché non è provato. Quando un utente reimposta una password, la conferma non dovrebbe valere anche come verifica, e viceversa. Testare questi percorsi significa controllare che un token coniato per uno scopo venga rifiutato dall’altro, che è una piccola asserzione che previene una grande classe di bug.
Una fixture utile per questo lavoro è una casella che nessun altro caso sta usando, così che il messaggio che apri sia certamente quello appena inviato dal flusso. Lo strumento di posta temporanea crea esattamente quel tipo di indirizzo, e l’articolo sul test OTP nelle suite end-to-end si occupa di estrarre il codice una volta arrivato.
Cosa dovrebbe succedere quando la posta non arriva mai?
Questo è il percorso che i team saltano, ed è quello che gli utenti incontrano più spesso, perché la posta fallisce per ragioni che nessuno controlla: un refuso nell’indirizzo, un fornitore che scarta il messaggio in silenzio, un mittente temporaneamente limitato.
Il flusso dovrebbe trattare la mancata consegna come un esito normale. L’utente dovrebbe poter chiedere un altro messaggio senza attendere un tempo irragionevole, l’interfaccia dovrebbe dire chiaramente che il messaggio può richiedere un momento, e l’account non dovrebbe essere lasciato in uno stato in cui l’utente non può chiedere di nuovo perché una richiesta è già in sospeso. Qui non c’è un numero specifico di secondi o di tentativi; il punto è che il progetto abbia una risposta.
Leggere un codice da una casella sacrificabile
Quando un flusso invia un codice breve invece di un link, il test ha bisogno del codice dal messaggio. Leggerlo da una casella creata per l’esecuzione mantiene l’asserzione ristretta: il messaggio che trovi può appartenere solo al caso che stai eseguendo, il che rimuove la causa più comune di un test che passa per la ragione sbagliata.
Tiene anche le caselle reali del tutto fuori dal test. L’indirizzo di un collega non dovrebbe mai essere il destinatario della tua suite di regressione, sia perché riceverebbero il traffico sia perché le tue asserzioni dipenderebbero allora da una casella che non controlli.
Per gli sviluppatori: token, idempotenza e il percorso infelice
Modella il token, non solo il modulo. Tre proprietà meritano una copertura esplicita.
L’uso singolo è la prima. Un token dovrebbe essere consumabile una volta, e il secondo tentativo dovrebbe essere un esito benigno anziché un errore del server. Dove la transizione cambia qualcosa di importante, rendi l’operazione idempotente, così che una ripetizione produca lo stesso stato finale invece di un secondo effetto.
La scadenza è la seconda. I token scaduti dovrebbero essere distinguibili da quelli non validi nei tuoi log e dal punto di vista dell’utente, perché i rimedi differiscono: un token scaduto significa ricominciare, un token non valido può significare che è stato copiato il link sbagliato. Ciò che un token scaduto non deve fare è lasciare l’account in uno stato cambiato a metà.
La concorrenza è la terza. Due clic che arrivano insieme, o un link aperto in due schede, non dovrebbero poter verificare lo stesso flusso due volte. È una proprietà dello strato dati, non del pulsante, quindi testalo inviando entrambe le richieste invece di cliccare due volte lentamente.
Infine, mantieni chiaro il confine nelle tue fixture e nelle tue note: questi indirizzi esistono per ricevere posta di test per un momento, non sono identità reali, e nessuna fixture dovrebbe implicare il contrario.
Prossimi passi
Prendi il flusso di verifica che hai rilasciato più di recente e percorri la tabella degli stati qui sopra, segnando le transizioni che hai davvero testato. Poi esegui quelle che non hai testato, usando un indirizzo creato nuovo per ogni caso dalla pagina della posta temporanea. Se stai preparando un lancio più ampio, la checklist per il test delle email transazionali copre la posta circostante che un account verificato inizierà a ricevere.