Email fake per i test: indirizzi sicuri per i moduli di registrazione
Se crei o testi siti, passi il tempo a scrivere indirizzi email nei moduli. L'unica cosa che non deve mai succedere è che un messaggio di prova finisca nella casella vera di uno sconosciuto. Questa pagina ti mostra quale email fake usare per ogni tipo di test — e quando il messaggio deve arrivare davvero.
Prima decidi se la posta deve arrivare
Questa sola domanda decide tutto, e vale la pena farsela in modo esplicito, perché la risposta è «no» più spesso di quanto si pensi.
| Cosa stai testando | La posta deve arrivare? | Usa |
|---|---|---|
| Validazione, salvataggio o visualizzazione di un indirizzo | no | un dominio riservato — vedi sotto |
| Il flusso di conferma, a mano | sì | una casella di qui |
| Il flusso di conferma, automatizzato | sì, leggibile dal codice | un servizio con API |
| Test di carico o di volume | no — e non deve | sempre un dominio riservato |
Quando la posta non deve arrivare: nomi riservati
Esistono domini fatti apposta per questo, che per garanzia non saranno mai di nessuno: example.com e i suoi fratelli example.net ed example.org, riservati dalla RFC 2606, più l'intera estensione .test.
Gli indirizzi su questi domini sono la risposta giusta per dati di esempio, dati iniziali e test di carico. Niente di ciò che invii può arrivare a una persona, perché lì non c'è nessuno — per accordo internazionale, non per fortuna.
test@mycompanytest.com si rivela abbastanza spesso il dominio vero di qualcuno, e un test di carico puntato lì non si distingue da un attacco. I nomi riservati non costano nulla ed eliminano l'intera categoria di incidenti.Quando la posta deve arrivare, a mano
Prendi un indirizzo qui, avvia il flusso e leggi cosa ha inviato davvero la tua applicazione — intestazioni, link e come appare il messaggio quando non è il tuo programma di posta a mostrarlo. Due cose che così si scoprono e che un catturatore di posta locale non vede:
- La consegna vera. Il messaggio percorre una vera strada di posta, quindi un mittente configurato male fallisce qui e non in produzione.
- Come lo vede uno sconosciuto. Link che funzionano solo nella tua sessione, immagini che non si caricano mai, un link di disiscrizione che punta a localhost — si vede tutto subito.
Guarda anche gli avvisi sugli allegati, se la tua applicazione invia file: sono gli stessi avvisi che vedranno i tuoi utenti.
Quando deve essere automatizzato
Leggere la pagina con uno script è un pessimo affare anche quando funziona: è fragile, non documentato ed è proprio il tipo di traffico che prima o poi viene bloccato.
Testare i casi di rifiuto
I fallimenti interessanti non sono «un indirizzo valido funziona». Vale la pena coprire:
- Un indirizzo su un dominio senza record MX — la consegna fallisce anche se l'indirizzo è scritto bene. Il tuo codice dovrebbe distinguere i due casi. Controlla quale è quale.
- Un dominio internazionalizzato, sia in Unicode sia nella forma
xn--. La maggior parte dei validatori ne rifiuta una e accetta l'altra, e di solito al contrario — convertitore. - Le varianti Gmail con punti e con il più. Se il tuo controllo di unicità confronta le stringhe così come sono, una sola persona può creare account senza limiti. Normalizza prima — quella pagina fa esattamente ciò che dovrebbe fare il tuo controllo.
- Una parte locale molto lunga. Lo standard ammette 64 caratteri; molti moduli tagliano in silenzio a 20 e salvano qualcosa che non porta più da nessuna parte.
Qualcosa da costruire, non da testare
Se il tuo prodotto non accetta indirizzi email fake, rifiutali con chiarezza. «Email non valida» per un indirizzo perfettamente valido è l'errore più confuso del genere: l'utente controlla l'ortografia, riscrive e riceve lo stesso messaggio. «Non accettiamo indirizzi email fake» occupa lo stesso spazio e mette fine alla confusione.