La versione inaffidabile di un test email è breve: crea un indirizzo, attendi cinque secondi, leggi il primo messaggio e spera che appartenga a questa esecuzione.
La versione affidabile è ancora semplice, ma tratta la consegna come asincrona. Crea un indirizzo unico, registra l'ora di inizio, effettua polling entro una scadenza, corrisponde al messaggio previsto, valida l'azione del prodotto e fornisce contesto sufficiente quando qualcosa fallisce.
Mantieni la chiave API fuori dall'URL
Invia la chiave GPTMail nell'intestazione X-API-Key. Non inserirla nei parametri di query ?api_key=. Gli URL vengono regolarmente memorizzati nella cronologia del browser, nei log di accesso, nei sistemi di monitoraggio e nei dati di referrer.
X-API-Key: YOUR_API_KEYMemorizza la chiave nel gestore di segreti del tuo CI e mascherala nei log. Una chiave pubblica giornaliera è comoda per l'esplorazione; le suite automatizzate controllate dovrebbero usare una chiave di cui puoi monitorare la quota e l'utilizzo.
Gli endpoint attuali e gli esempi di risposta sono mantenuti nella pagina di documentazione dell'API GPTMail.
Un indirizzo per esecuzione
Genera un nuovo indirizzo per ogni test eseguibile in modo indipendente. Non basare la correttezza su una casella condivisa da un'intera suite di test.
Registra l'indirizzo, l'ID dello scenario, l'ambiente e l'ora di inizio del test. Questi valori ti permettono di scartare messaggi obsoleti e diagnosticare collisioni senza registrare segreti dei messaggi.
Esegui il polling fino a una scadenza, non con un'attesa fissa
Il tempo di consegna delle email varia. Un'attesa fissa di cinque secondi è sia uno spreco quando la consegna è rapida, sia inaffidabile quando è lenta.
Usa un ciclo limitato:
deadline = now + 90 seconds
delay = 2 seconds
while now < deadline:
messages = list inbox
candidate = newest message matching sender, subject, and start time
if candidate exists:
read candidate and continue the product test
wait delay with a small random jitter
delay = min(delay * 1.5, 10 seconds)La scadenza fa parte del contratto del test. Un flusso di reset della password può richiedere un limite diverso rispetto a un'anteprima di newsletter di massa. Mantieni il limite esplicito affinché una dipendenza lenta non allunghi silenziosamente l'intero job CI.
Corrispondi con precisione
“Il primo messaggio nella casella” non è un selettore utile. Corrispondi a diversi segnali:
- il destinatario è uguale all'indirizzo creato per questa esecuzione;
- l'ora di creazione è successiva all'ora di attivazione;
- il mittente appartiene al servizio previsto;
- l'oggetto o il tipo di messaggio corrisponde al flusso;
- l'ID del messaggio non è già stato consumato.
Quando il mittente può inviare più codici, seleziona il messaggio più recente che corrisponde. Conserva il suo ID nell'output del test in modo che i retry non lo riutilizzino accidentalmente.
Leggi solo dopo una corrispondenza nella lista
L'elenco della casella dovrebbe essere il passaggio di scoperta a basso costo. Recupera il messaggio completo solo per il candidato selezionato. Questo riduce lavoro non necessario ed evita di analizzare email promozionali non correlate.
Convalida il risultato di business, non solo la presenza di una stringa a sei cifre. Invia il codice o apri il link previsto, quindi verifica che l'account raggiunga lo stato corretto.
Gestisci i limiti di velocità come segnale
Se l'API restituisce una risposta di quota o di limite di velocità, interrompi il tentativo corrente e mostra le informazioni di reset. Retry aggressivi trasformano un chiaro segnale di capacità in rumore e possono ritardare test non correlati.
Limita la concorrenza nel runner dei test, specialmente quando una suite crea molti indirizzi contemporaneamente. Un piccolo pool di worker è più facile da debug rispetto a centinaia di loop di polling simultanei.
Pulizia senza nascondere i fallimenti
La pulizia dovrebbe essere eseguita dopo aver catturato le prove. In caso di successo, rimuovi i messaggi o lascia che la breve conservazione li gestisca. In caso di fallimento, conserva l'indirizzo e l'ID del messaggio negli artefatti CI protetti per un tempo sufficiente all'indagine, poi eliminali.
Non stampare mai codici di verifica, link privati o interi corpi HTML nei log di build pubblici.
Rendi i retry idempotenti
Riprova il test come una nuova esecuzione con un nuovo indirizzo. Non presumere che ripetere la stessa richiesta contro lo stesso account e casella parta da uno stato pulito. Il mittente può invalidare i codici vecchi, limitare le richieste ripetute o rifiutare inviti duplicati.
Se una richiesta di rete scade, distingui “nessuna risposta ricevuta” da “l'operazione non è avvenuta”. Controlla lo stato osservabile prima di effettuare un retry distruttivo.
Segnala il punto di fallimento
Un fallimento di automazione utile identifica una di queste fasi:
- generazione dell'indirizzo fallita;
- azione del prodotto fallita prima dell'accodamento dell'email;
- nessun messaggio corrispondente arrivato prima della scadenza;
- messaggio arrivato ma il contenuto non corrispondeva;
- azione di verifica fallita;
- pulizia fallita.
Questa classificazione trasforma un intermittente “test email fallito” in un lavoro che un team può gestire.
Per la matrice di test più ampia, leggi Un vero piano di test delle email. Per la diagnosi della consegna, usa Email di Verifica Non Arriva: Trova il Passo Interrotto.