L’email temporanea gratuita è il punto di partenza predefinito per i team che hanno bisogno di una casella in un test e non hanno una voce di budget per averla. Non costa nulla provarla, non richiede un dominio e funziona abbastanza bene la prima volta. I problemi iniziano quando lo stesso approccio viene cablato in una pipeline che gira ogni notte, perché le proprietà che rendono comoda una casella pubblica gratuita sono le stesse che la rendono inaffidabile su larga scala.
Questa guida spiega cosa compra davvero la parola gratis, perché i domini pubblici condivisi finiscono nelle liste di blocco, come un dominio che controllate cambia l’aritmetica e come un team senza budget può comunque costruire test email che non falliscono per ragioni estranee al software. Alla fine dovreste essere in grado di decidere se il gratis è sufficiente per un dato test o è solo un costo rinviato.
Cosa include e cosa non include l’email temporanea gratuita?
Una casella pubblica gratuita include un indirizzo su un dominio condiviso, un’interfaccia web per leggere i messaggi e una finestra di conservazione misurata in minuti o ore. Esclude le cose che contano una volta che i test diventano routine: un periodo di conservazione garantito, una quota di frequenza su cui potete pianificare, il controllo del dominio e qualsiasi impegno su quando il servizio cambierà.
La finestra di conservazione è la prima variabile nascosta. I fornitori gratuiti conservano i messaggi per un periodo che scelgono loro e possono accorciarlo senza preavviso. Un test di verifica che attende un messaggio, e una casella che scade mentre il test dorme, producono un errore che sembra un problema di consegna ed è in realtà un problema di conservazione.
La quota di frequenza è la seconda. I fornitori limitano quante caselle possono essere create da una singola fonte in un periodo, e il limite non è pubblicato in una forma su cui possiate pianificare. Una suite che crea una casella per caso di test scoprirà il limite da qualche parte a metà esecuzione, e gli errori saranno distribuiti in modo imprevedibile su tutta la suite.
Il dominio è la terza e più grande. Ogni utente di un fornitore gratuito condivide lo stesso dominio, il che significa che la recapitabilità del vostro test è funzione di ciò che hanno fatto gli sconosciuti quella settimana. Non c’è nulla che possiate fare per migliorarla e nulla che possiate fare per spiegarla a un collega che legge una build fallita. Un fornitore gratuito può anche sospendere un indirizzo o l’intero dominio senza preavviso, e l’unico sintomo visibile è che il messaggio che stavate aspettando non arriva mai.
Perché i domini pubblici condivisi finiscono nelle liste di blocco
I prodotti di registrazione vogliono fermare la creazione automatizzata di account, e uno dei segnali più economici disponibili è il dominio email. Un elenco pubblicato di domini usa e getta permette a un modulo di respingere un invio con un singolo confronto, prima che venga controllata qualsiasi password e prima che venga inviata qualsiasi posta. L’elenco è mantenuto da fornitori, aggiornato continuamente e consumato da migliaia di prodotti.
La meccanica con cui un dominio finisce su un simile elenco è banale. Si osserva che un dominio accetta posta per indirizzi che non sono mai stati registrati, oppure che emette indirizzi a una velocità che nessun umano potrebbe sostenere, oppure che viene usato in segnalazioni di abuso. Una sola di queste osservazioni è sufficiente, e nessuna di esse richiede che abbiate fatto qualcosa di sbagliato. I livelli gratuiti sono anche sproporzionatamente rappresentati su questi elenchi, perché un servizio che non costa nulla da usare è lo strumento più economico possibile per qualcuno che crea account in massa, e un dominio che attira quel traffico viene notato rapidamente.
Per i test, la conseguenza è che la lista di blocco è una dipendenza dell’ambiente che non possedete. Una pipeline che passa venerdì e fallisce lunedì non ha alcuna modifica nel proprio repository per spiegare la differenza, e il percorso di debug standard — leggete il diff, riproducete in locale — non troverà nulla. L’articolo perché i siti bloccano i domini usa e getta copre il lato del rilevamento, compresi i controlli che vanno oltre l’elenco dei domini stesso.
C’è un’ulteriore complicazione per gli ambienti di staging. Molti team disattivano il blocco dei domini usa e getta nello staging affinché i propri test passino, il che significa che la lista di blocco non viene mai esercitata. Un difetto nella logica di blocco raggiunge quindi la produzione non testato, e la prima segnalazione arriva da un utente anziché da una build.
Possedere il dominio cambia l’aritmetica?
Cambia quasi tutto ciò che era instabile. Quando il dominio appartiene a voi, la questione della recapitabilità riguarda la vostra reputazione di invio anziché una condivisa, la finestra di conservazione è quella che fa la vostra casella, la quota di frequenza è la vostra infrastruttura e nessun elenco di terze parti decide se il vostro test passa.
Il costo non è zero anche quando il denaro è zero. Serve un dominio, un record MX, una casella o uno script di elaborazione, e qualcuno che capisca perché la posta da un nuovo dominio a volte finisce nello spam. Quello è un costo reale in attenzione, ed è il motivo per cui i team si rivolgono ai fornitori pubblici in primo luogo.
Il ritorno è una suite di test che fallisce solo quando fallisce il software. Quella proprietà vale più di quanto sembri, perché una suite con errori inspiegati viene ignorata, e una suite ignorata non protegge nulla. Una volta che il percorso della posta è sotto il vostro controllo, un errore nel flusso di verifica significa un difetto nel flusso di verifica. L’articolo casella catch-all per lo staging descrive la versione più piccola di questa configurazione.
C’è un’opzione intermedia di cui vale la pena sapere: un servizio pubblico di posta di test che emette indirizzi su un dominio riservato ai test anziché su un dominio usa e getta generico. È meno probabile che questi vengano inseriti nelle liste di blocco perché non sono commercializzati verso i consumatori, ma sono comunque una terza parte, e valgono le stesse domande sulla disponibilità.
Come dovrebbe progettare test email affidabili un team a budget zero
Iniziate rimuovendo la consegna dalla maggior parte dei vostri test. Un server di cattura locale che riceve i messaggi invece di inviarli copre il rendering dei template, l’estrazione dei link e l’estrazione dei codici, e gira in millisecondi senza dipendenze di rete. L’articolo cattura SMTP locale in CI tratta questo come impostazione predefinita per un motivo: la maggior parte delle asserzioni sulla posta riguarda il contenuto, non il trasporto.
Riservate la consegna reale a un piccolo numero di test che ne hanno davvero bisogno. La verifica end-to-end, la scadenza dei link e l’interazione tra il mailer e un fornitore esterno sono i casi che giustificano un messaggio reale, e di solito ce ne sono una manciata anziché centinaia. Mantenere piccolo quell’insieme è ciò che rende conveniente eseguirlo su un’infrastruttura che controllate.
Se dovete usare una casella pubblica gratuita, isolatela in un job proprio. Uno stadio separato della pipeline che è autorizzato a essere instabile, con un nuovo tentativo e un messaggio di errore chiaro, impedisce che un’interruzione di terze parti sia indistinguibile da una regressione. Marcare quei test in modo che possano essere saltati durante un blocco delle release è un compromesso pragmatico, a condizione che la perdita di copertura sia messa per iscritto.
Rendete la casella identificabile in ogni caso. Un prefisso che registra l’ambiente, l’esecuzione e il caso di test rende tracciabile un messaggio ricevuto e rende possibile la pulizia. Una casella senza etichetta che accumula un anno di messaggi è un passivo di conservazione, non un asset di test. L’articolo checklist di test per email transazionali raccoglie le asserzioni che vale la pena fare una volta catturato un messaggio. Queste regole sono anche quelle attorno a cui è progettato il generatore di temp mail su questo sito, e si applicano sia che la casella sia gratuita sia a pagamento.
Quali opzioni gratuite sono effettivamente accettabili
Un’opzione gratuita è accettabile quando la sua modalità di fallimento è visibile e il suo raggio d’azione è piccolo. Una casella usata una volta, a mano, per confermare che un’email di reimpostazione della password arrivi e venga renderizzata correttamente è un buon uso di un dominio usa e getta gratuito. Nulla dipende da essa domani, e se il dominio viene bloccato ve ne accorgerete immediatamente.
Diventa inaccettabile quando lo stesso tipo di casella si trova sul percorso critico di una suite automatizzata. Se la pipeline si blocca in attesa che un messaggio arrivi a un dominio controllato da qualcun altro, allora l’affidabilità della pipeline è funzione di un servizio che non ha obblighi verso di voi, nessun periodo di preavviso e nessun incentivo a preoccuparsi della vostra build. L’aritmetica è facile da sottovalutare quando l’unico costo visibile è zero, perché il costo invisibile è l’attenzione spesa su errori che non sono il cambiamento di nessuno.
Un test utile è chiedere cosa succede quando il fornitore scompare senza preavviso. Se la risposta è che una build diventa rossa e qualcuno passa un pomeriggio a indagare, l’opzione gratuita costa più di un dominio. Se la risposta è che un controllo manuale non può essere eseguito finché non si trova un sostituto, il costo è compreso e accettabile.
Aiuta anche contare onestamente i costi di secondo ordine, perché il gratis raramente resta gratis in termini di tempo del personale. Qualcuno deve imparare come si comporta il fornitore, scrivere la logica di nuovo tentativo e rispondere alla domanda sul perché la build notturna è fallita di nuovo. Moltiplicate quell’attenzione per il numero di mesi in cui gira la suite e confrontatela con un pomeriggio speso a configurare un dominio e uno script di cattura. Il confronto di solito favorisce la via a pagamento, ed è per questo che così tanti team finiscono per possedere comunque un dominio.
C’è anche una domanda più semplice: il flusso testato si comporta allo stesso modo per un indirizzo su dominio gratuito e per uno normale? Se il vostro prodotto blocca i domini usa e getta, allora usare un dominio usa e getta nel test significa che state testando il percorso di rifiuto, non quello di successo. Confondere i due è un errore comune e costoso.
Per cosa non devono essere usati i messaggi e gli indirizzi
Un indirizzo generato per i test è un record sintetico. Non appartiene a una persona, non è un punto di contatto che qualcuno monitora e non deve essere usato per impersonare qualcuno, per ottenere accesso ad account che non sono vostri, per estendere una prova gratuita oltre i suoi termini, per aggirare un limite di frequenza o un controllo di verifica, o per ricevere posta che conta per qualcuno.
Quest’ultimo punto merita enfasi in una discussione sul budget, perché la tentazione di usare una casella gratuita per qualcosa di diverso dai test è più forte quando le risorse sono scarse. Un indirizzo di assistenza, un contatto di fatturazione o un punto di recupero password ospitato su un dominio che scade è un passivo per qualunque cosa vi sia collegata, a prescindere dalla questione se sia consentito.
Trattate anche i messaggi catturati come di breve durata. Sono email reali, possono contenere valori reali che sono trapelati attraverso un template, e una casella di staging senza politica di eliminazione finirà per contenere qualcosa che non dovrebbe. Eliminate secondo una pianificazione e tenete il periodo di conservazione scritto dove il team può vederlo.
Tutto ciò che è discusso qui serve a esercitare il vostro stesso software. Gli indirizzi e le caselle generati sono artefatti di test, non identità, e non possono essere usati per superare una verifica reale, per aprire un conto reale a nome di qualcuno o per rappresentare i dettagli di contatto di qualcuno.