Un messaggio di conferma è la parte di un flusso di registrazione che un test del browser non può guidare da solo. Qualcosa deve possedere un indirizzo, ricevere il messaggio e restituire il codice al test. Un’API di casella temporanea fa esattamente questo: la suite chiede a un servizio di creare una casella via HTTP, legge ciò che arriva e getta la casella quando il caso è finito. Non c’è browser, non c’è una casella umana condivisa e non c’è copia e incolla manuale.
Questo articolo riguarda il lato API di questa disposizione. Non riguarda il puntare l’applicazione a un endpoint locale di ricezione: quello è come catturare email in CI, e i due risolvono problemi diversi. La cattura locale dimostra ciò che la tua applicazione invia. Un’API di casella dimostra ciò che arriva davvero, lungo un percorso di consegna reale, a un indirizzo che il test possiede.
Perché usare un’API di casella nei test?
Perché l’alternativa è una vera casella umana oppure niente.
Una casella condivisa è un’infrastruttura di test scadente. Diverse esecuzioni leggono la stessa casella, i messaggi di un’esecuzione precedente sono ancora lì, e l’indirizzo accumula traffico che nessun test ha richiesto. Ogni asserzione deve allora indovinare quale messaggio appartiene al caso corrente, e nell’indovinare nasce l’instabilità.
Raccogliere l’interfaccia web di un fornitore con un browser è la seconda cattiva opzione. Rende il test dipendente da markup che cambia senza preavviso, dallo stato di sessione e da un accesso che la suite deve sorvegliare. Nel momento in cui il fornitore ridisegna un pulsante, una suite verde diventa rossa per un motivo che non ha nulla a che fare con il prodotto.
Un’API di casella elimina entrambi i problemi. L’indirizzo è creato per il caso, è vuoto per costruzione, e si legge attraverso un’interfaccia stabile che il test può chiamare direttamente. Alla suite non importa più come appare il fornitore, solo che il contratto regga: crea, ricevi, leggi, elimina.
C’è anche un argomento di privacy. Un indirizzo creato tramite API non rappresenta nessuno. Non è la casella di una persona, non è un luogo dove potrebbe finire un messaggio reale, ed è gettato via con l’esecuzione.
Di quali endpoint ha davvero bisogno un test?
Un’API di casella può esporre decine di rotte, ma un client di test ha bisogno di quattro operazioni, e aiuta nominarle come la suite le userà.
Crea restituisce un indirizzo e un handle. L’indirizzo è ciò a cui l’applicazione sotto test viene indirizzata. L’handle, spesso un token o un identificatore, è ciò che il test usa per chiedere di quella casella in ogni chiamata successiva. La suite deve trattare la coppia come un unico oggetto e non ricostruire mai l’handle dall’indirizzo, perché i fornitori sono liberi di rendere i due non correlati.
Elenca restituisce riassunti anziché corpi: una voce per messaggio, con un identificatore, il mittente, l’oggetto e l’ora di arrivo. È la chiamata che un ciclo di interrogazione dovrebbe usare, perché è economica ed è sufficiente a rispondere all’unica domanda che conta all’inizio: se è già arrivato qualcosa.
Leggi restituisce un messaggio per intero, comprese le parti di testo e HTML. È lì che vive il codice, ed è la chiamata da fare solo dopo che elenca ha segnalato una corrispondenza.
Pulisci rimuove i messaggi da una casella o elimina la casella del tutto. Un test ne ha bisogno per due ragioni: azzerare tra i tentativi senza creare un nuovo indirizzo, e ripulire quando il caso finisce.
Alcuni servizi aggiungono un endpoint di attesa o di polling lungo, che tiene la connessione finché arriva un messaggio o scade un tempo limite. È comodo, ma un client dovrebbe comunque poter ripiegare su elenca, perché la chiamata di attesa è la parte più soggetta ai limiti di frequenza.
Interrogare il codice senza instabilità
L’errore più comune in questo tipo di test è l’attesa fissa. Un numero costante di secondi è una congettura: troppo corta quando la consegna è lenta, inutilmente lunga quando è veloce, e sbagliata in entrambe le direzioni su un runner di CI carico. Sostituiscila con un ciclo che chiama elenca, verifica una corrispondenza e ritorna appena la trova, con un tetto che fa fallire il test invece di bloccare il processo.
La corrispondenza è la seconda metà del problema. Il messaggio che il test vuole è quello indirizzato all’indirizzo creato dal caso e, se la casella può contenere più di un tipo di posta, quello il cui oggetto porta un frammento stabile. Preferisci la corrispondenza più recente, così una consegna duplicata da un tentativo non confonde la lettura. Non prendere mai il primo messaggio senza criterio; su un indirizzo riutilizzato è esattamente così che un vecchio codice finisce con l’essere convalidato.
L’estrazione deve essere ancorata. Un corpo può contenere un numero di riferimento, un timestamp e un prezzo, e un parser che prende la prima serie di cifre a volte prende una di quelle invece del codice. Cerca la dicitura che introduce il codice, leggi il codice nel suo intorno, e fallisci con il corpo allegato quando non corrisponde nulla.
Infine, rispetta il limite di reinvio. Un flusso con codice in genere consente solo pochi invii in una finestra breve, e quel limite fa parte del comportamento sotto test. Un test che preme di nuovo il pulsante per ottenere un codice fresco prima o poi verrà rifiutato e fallirà per il motivo sbagliato. Riprova leggendo di nuovo la casella, non attivando un altro messaggio.
Inserirla in una suite end-to-end o di CI
La forma pulita è un’infrastruttura di test. Prima che il flusso inizi, questa crea una casella e ne restituisce l’indirizzo. Il test guida l’applicazione usando quell’indirizzo. Dopo che l’applicazione conferma di aver inviato qualcosa, l’asserzione legge la casella ed estrae il codice. Quando il caso finisce, l’infrastruttura elimina la casella.
Mantieni il client piccolo e iniettabile. Un modulo avvolge le quattro chiamate; il test dipende da quel modulo, mai da HTTP grezzo sparso nella suite. Questo permette di sostituirlo con un doppio nei test unitari e di puntare la stessa suite a un fornitore diverso senza riscrivere le asserzioni.
In CI le credenziali appartengono al deposito di segreti del job, mai al repository e mai a una riga di log. Dai a ogni job o a ogni worker parallelo la propria casella, e anteponi agli indirizzi generati un prefisso che identifichi l’esecuzione, così che un messaggio vagante sia attribuibile a colpo d’occhio. Imposta il timeout del client sotto il timeout del job stesso, così un’interrogazione bloccata fallisce con un messaggio chiaro invece di una cancellazione brusca.
Riprova la lettura, non l’intero flusso. Se il codice non è ancora arrivato, aspetta e leggi di nuovo; rifare la registrazione produrrebbe un secondo messaggio e, con esso, un secondo candidato per l’asserzione. E tieni l’API di casella fuori dai flussi di produzione: è infrastruttura di test, e una suite non dovrebbe mai poter inviare a un cliente reale da essa.
Il flusso attorno al codice, più che la meccanica della sua lettura, è trattato in test del flusso di verifica email, e il passo di analisi in particolare è l’oggetto di test OTP nelle suite end-to-end.
Isolamento e pulizia
Un indirizzo per caso è la regola che previene la maggior parte dei guasti tra test. Elimina il bisogno di ragionare su quale messaggio appartenga a chi, e fa sparire la questione della freschezza, perché la casella ha ricevuto solo il traffico di un caso.
La pulizia deve essere esplicita e incondizionata. Elimina la casella in una fase di smontaggio che gira sia se il caso passa sia se fallisce, non solo sul percorso felice. Affidarsi al solo tempo di vita del fornitore è un errore: il messaggio può restare abbastanza a lungo da essere letto da un’esecuzione successiva sulla stessa macchina, e quella durata è una comodità, non una garanzia.
Se la pulizia fallisce, registralo e lascia che la suite finisca. Un errore di pulizia merita di essere conosciuto, ma non è la stessa cosa di un difetto di prodotto, e far fallire l’esecuzione per esso insegna al team a ignorare i guasti di smontaggio. Tratta tutto ciò che l’indirizzo ha ricevuto come dati di test: esiste per una sola asserzione, non va esportato né condiviso, e non va mai considerato il punto di contatto di qualcuno.
Limiti e avvertenze
Un’API di casella resta una dipendenza di terze parti, e i suoi limiti diventano i tuoi. I limiti al minuto possono rifiutare una raffica di creazioni da un’esecuzione parallela ampia. Le quote limitano quante caselle esistono insieme. I messaggi possono ritardare, e un messaggio ritardato appare identico a uno mancante finché non arriva.
Anche i domini usa e getta sono ampiamente bloccati. Il dominio di un fornitore può essere rifiutato proprio dal modulo di registrazione che stai testando, il che trasforma un test legittimo in un guasto confuso. Quando accade, la risposta non è fare un’eccezione per il fornitore, ma capire se il prodotto sotto test respinge di proposito gli indirizzi usa e getta, e testare quel comportamento di proposito.
Il riassunto onesto è che l’API di casella è lo strumento giusto per affermare ciò che arriva. Per affermare ciò che la tua applicazione emette, un endpoint locale di ricezione è più veloce e non ha quota. La maggior parte delle suite mature usa entrambi: cattura locale per il grosso delle asserzioni, e un’API di casella solo dove il vero percorso di consegna è ciò che viene testato.
Passi successivi
Trova un test che legge un codice interrogando una casella condivisa e sostituiscilo con un’infrastruttura che crea un indirizzo fresco da un’API di casella. Registra l’indirizzo con l’esecuzione, eliminalo allo smontaggio, e osserva quanta dell’instabilità che avevi accettato smette semplicemente di accadere. Quando ti serve una casella reale a mano, la pagina della posta temporanea ne crea una in un attimo, e gli indirizzi che distribuisce sono impalcature per un’esecuzione, mai un’identità reale.