Un generatore di temp mail crea una casella di breve durata con un indirizzo funzionante, così che un modulo di registrazione, un flusso di reimpostazione della password o una consegna di codice monouso possano essere esercitati dall’inizio alla fine anziché simulati. La casella accetta posta reale, la conserva per un po’ e poi scompare — che è esattamente la proprietà che la rende utile in un test e inutilizzabile come contatto permanente.
Questa guida separa le tre cose che le persone intendono quando parlano di email temporanea, spiega cosa risolve una casella usa e getta che uno stub non può risolvere, perché così tanti servizi rifiutano questi domini e quando invece non dovreste ricorrervi affatto. Alla fine dovreste essere in grado di scegliere tra un dominio usa e getta pubblico, un alias di inoltro e una casella catch-all sul vostro dominio senza tirare a indovinare, e il generatore di temp mail su questo sito è il compagno pratico di quella decisione.
Che cos’è una casella usa e getta?
Una casella usa e getta è una casella che esiste per un breve periodo e può essere creata senza alcuna registrazione. Ha un indirizzo, può ricevere posta e ha una scadenza. Tutto il resto varia da fornitore a fornitore: quanto dura la conservazione, se l’indirizzo è indovinabile, se la casella è pubblica e se gli allegati vengono memorizzati.
Di solito l’indirizzo si trova su un dominio condiviso. Questo è il fatto strutturale importante, perché significa che il dominio è usato da migliaia di persone non correlate allo stesso tempo, e significa che la reputazione del dominio è condivisa tra tutte loro. Quando un utente di quel dominio ne abusa, ogni altro utente eredita la conseguenza sotto forma di una voce in qualche lista di blocco. Niente nella casella stessa vi dice quali sconosciuti hanno usato il dominio questa settimana, e niente che facciate nel vostro test può migliorare la posizione che ereditate da loro.
La casella non è un alias di inoltro, e questa è la distinzione più spesso confusa. Un alias appartiene a un dominio che controllate e inoltra a una casella che già possedete, quindi la casella sottostante è permanente e l’alias è un puntatore. Una casella usa e getta è la casella stessa, e dietro di essa non c’è nulla una volta scaduta.
In che modo le caselle temporanee differiscono da alias e domini catch-all
Un alias di inoltro è un’identità stabile con una durata voluta. Lo create una volta, lo puntate a una casella reale e lo usate ovunque un servizio chieda un indirizzo email. La posta arriva al vostro account, l’alias può essere disattivato in seguito e, poiché il dominio appartiene a voi, la recapitabilità di quell’alias è la vostra reputazione anziché quella di uno sconosciuto.
Un dominio catch-all è la versione industriale della stessa idea. Ogni indirizzo del dominio — non solo quelli che avete creato — viene accettato e instradato verso una casella o uno script di elaborazione. Ciò permette di generare un indirizzo nuovo per ogni esecuzione di test senza alcun passaggio di provisioning, perché l’indirizzo è valido nel momento stesso in cui viene inventato. L’articolo casella catch-all per lo staging copre i dettagli operativi e l’esposizione allo spam che ne deriva.
Una casella usa e getta pubblica si colloca all’altro estremo del compromesso. Non costa nulla e non richiede record DNS e, in cambio, condivide un dominio con tutti gli altri, ha una finestra di conservazione che non avete scelto e può essere bloccata proprio dal servizio che state testando. Per un controllo manuale rapido è comoda. Per una pipeline notturna è una fonte di errori intermittenti difficili da attribuire.
Cosa risolve una casella usa e getta nei test di verifica?
Il problema che risolve è specifico: un flusso che invia un link o un codice a un indirizzo e poi attende che qualcuno ne faccia qualcosa. Un mailer simulato può confermare che un messaggio è stato messo in coda. Non può confermare che il link nel messaggio funzioni, che il codice nel messaggio venga accettato o che il token nel link scada quando dovrebbe.
Una casella reale colma quella lacuna. Il test si registra con un indirizzo generato, attende che il messaggio arrivi, estrae il link o il codice, lo segue e verifica il risultato. È l’unica forma di test che copre davvero il percorso di consegna, ed è il motivo per cui le caselle usa e getta esistono in un kit di test. L’articolo test dei flussi di verifica email illustra la versione più completa di quella sequenza.
C’è un secondo beneficio, più silenzioso. Una casella reale espone il messaggio come lo vedrà il destinatario, compreso il rendering, il nome del mittente, l’oggetto e l’ordine delle parti. Bug di template che uno stub non mostra mai — una variabile mancante, un link rotto, un oggetto che arriva vuoto — compaiono immediatamente quando una persona o un parser legge il messaggio reale. L’articolo checklist di test per email transazionali estende la stessa idea ai messaggi post-acquisto che nessun flusso di registrazione esercita.
Perché così tanti servizi bloccano i domini usa e getta
Il blocco funziona a partire da un elenco pubblicato di domini usa e getta. I fornitori vendono o regalano elenchi di domini associati alla posta temporanea, e un modulo di registrazione confronta l’indirizzo inviato con quell’elenco prima di ogni altra cosa. Il controllo è economico, non richiede alcuna verifica dell’utente e ferma una larga frazione di abusi automatizzati.
La conseguenza per i test è che la lista di blocco fa parte dell’ambiente in cui girano i vostri test, e non è sotto il vostro controllo. Un dominio che funziona oggi può comparire su un elenco domani, e la vostra pipeline inizierà a fallire senza alcun cambiamento da parte vostra. Questa è la causa singola più comune di errori di verifica intermittenti nelle suite automatizzate, ed è l’argomento dell’articolo perché i siti bloccano i domini usa e getta.
Peggio ancora, l’errore è spesso privo di informazioni. Il modulo restituisce un errore generico, il test segnala un timeout in attesa di un messaggio, e la causa reale — la registrazione è stata respinta prima che venisse inviata qualsiasi posta — è a diversi livelli di distanza dal sintomo. Una suite di test che usa domini pubblici condivisi è quindi una suite con un budget permanente e inspiegato di test instabili. Il rimedio è registrare l’indirizzo inviato e la risposta grezza del modulo ogni volta che un’attesa di consegna va in timeout, così che la prossima persona che vede l’errore abbia subito i due fatti che lo identificano.
Molti fornitori limitano anche la frequenza per dominio o per prefisso dell’indirizzo, il che introduce una seconda modalità di errore intermittente. Una pipeline che crea centinaia di caselle in pochi minuti può scoprire che il fornitore ha iniziato a rifiutare, e di nuovo il sintomo appare come un messaggio mancante anziché come una richiesta respinta.
Come dovrebbe progettare il percorso della posta una suite di test
Progettate il percorso della posta attorno a un dominio che controllate. Puntate un catch-all verso una casella o uno script di elaborazione e generate un indirizzo nuovo per ogni esecuzione combinando un token univoco con il dominio. Non serve alcun provisioning, la recapitabilità è una vostra responsabilità e nessun elenco di terze parti decide se la vostra pipeline passa.
Leggete il messaggio in modo programmatico, non a occhio. Un parser che estrae il primo link o il primo codice a più cifre dal corpo del messaggio rende l’asserzione deterministica, e un’asserzione deterministica è la differenza tra un test e una dimostrazione. L’articolo codici monouso nei test end-to-end copre le regole di estrazione che sopravvivono ai cambiamenti di template.
Per i test a livello di unità, saltate del tutto la consegna. Un server di cattura locale riceve il messaggio anziché inviarlo, il che mantiene il test veloce e rimuove la rete dal ciclo. L’articolo cattura SMTP locale in CI spiega perché questa è l’impostazione predefinita giusta per la maggior parte delle suite, con la consegna reale riservata al minor numero di test che ne hanno davvero bisogno.
Mantenete gli indirizzi riconoscibili. Un prefisso che identifica l’ambiente e l’esecuzione, seguito dal dominio che possedete, permette di risalire da un messaggio ricevuto al test che lo ha prodotto e di eliminare quelli non più necessari. Senza un prefisso, una casella catch-all condivisa diventa un mucchio di messaggi che nessuno riesce ad attribuire, e una casella inattribuibile è una casella che nessuno osa svuotare.
Quando non dovreste usare la posta temporanea
Ci sono casi in cui una casella usa e getta è lo strumento sbagliato, e vale la pena nominarli perché è facile caderci. Il primo è qualsiasi cosa che coinvolga un account reale che conta. Registrare un servizio da cui dipendete davvero con una casella che scadrà tra un’ora crea un account che non potete recuperare, e nessuna comodità lo giustifica.
Il secondo è un flusso che richiede di detenere dati di produzione. Una casella al di fuori della vostra organizzazione è fuori dalla vostra politica di conservazione e fuori dalla vostra pista di controllo, quindi qualsiasi messaggio contenente informazioni reali di clienti non deve mai passare attraverso una di esse. I regimi di conformità lo considerano una comunicazione illecita, non una scorciatoia per i test, e nessuna comodità durante uno sprint lo giustifica. Se un test ha davvero bisogno della forma di un messaggio di produzione, ricreate quella forma con valori sintetici anziché instradare il messaggio reale attraverso una casella di terze parti.
Il terzo è qualsiasi cosa che esista per aggirare un limite. Un indirizzo usa e getta non è un modo per ottenere prove ripetute di un servizio, e usarlo in quel modo è sia una violazione dei termini sia un segnale fuorviante su come il prodotto si comporta per un utente normale. La lettura onesta è che lo strumento esiste per testare i vostri stessi sistemi, e solo per quello.
Il quarto caso è più sottile: un flusso che deve sopravvivere più a lungo della finestra di conservazione. Se un test verifica una casella dopo un’ora, e la casella vive dieci minuti, il test fallirà per ragioni che non hanno nulla a che fare con il software in prova. Controllate la conservazione prima di inserire l’attesa nella suite e, se il fornitore non ne dichiara una, trattate quella come la risposta.
E i messaggi stessi?
Un messaggio ricevuto da una casella di test di solito è sintetico, ma è pur sempre una vera email generata da un sistema reale, e può contenere valori reali. Stringhe di sostituzione che non sono state renderizzate, hostname interni nei link di tracciamento e header di debug sono tutti ritrovamenti comuni, e tutti meritano di essere segnalati anziché ignorati.
Trattate la casella come un artefatto di breve durata ed eliminate i suoi contenuti quando un’esecuzione termina. Una casella di staging che accumula migliaia di messaggi non letti è un log senza politica di conservazione, e un log senza politica di conservazione finisce prima o poi per contenere qualcosa che non dovrebbe.
I messaggi che un test genera vi offrono anche un controllo di sicurezza a basso costo. Se un link di reimpostazione della password creato per un indirizzo funziona per un altro, o se un token di verifica non scade, il test basato sulla casella lo intercetterà in un modo che nessun test unitario può fare.
Ogni casella, indirizzo e messaggio discusso qui appartiene al test del software. Gli indirizzi generati sono record sintetici che esistono per esercitare i vostri stessi flussi, non devono essere usati per impersonare qualcuno, per accedere ad account che non sono vostri, per aggirare limiti di frequenza o controlli di verifica, o per ricevere posta che conta per qualcuno.