Risposta.

Storia della questione:

L'automazione del testing delle email di avviso è diventata rilevante con lo sviluppo dei sistemi di notifiche (ad esempio, durante la registrazione, cambiamento della password, promemoria). Inizialmente, tali test venivano eseguiti manualmente e verificati tramite email reale (cosa estremamente inefficace e non sicura in CI/CD). Successivamente, sono emersi strumenti specializzati (MailHog, Mailtrap, server SMTP falsi) che hanno reso possibile e sicura l'automazione.

Problema:

Le principali difficoltà sono legate al fatto che l'email viene inviata dal sistema "all'esterno", il che significa che è necessario: a) intercettare l'invio, b) assicurarsi del contenuto dell'email, c) verificare la correttezza dell'invio (formato delle intestazioni, presenza di allegati, link, i18n, correttezza del collegamento con eventi nel sistema). Si aggiungono difficoltà relative alla velocità di consegna, pulizia delle caselle tra i test, gestione degli errori SMTP.

Soluzione:

Utilizzare servizi speciali di intercettazione delle email: Mailtrap, MailHog, oppure server SMTP falsi integrati, che non consegnano email a caselle reali, ma le trattengono in una "cestino" di prova.
Integrare il lavoro con questi strumenti tramite un framework API o wrapper REST e implementare l'attesa delle email, la verifica dei parametri chiave delle email, la validazione degli allegati, la presenza di link corretti.
Generare email unique per i test, isolare i dati di test (ad esempio, utilizzare un dominio di test) e pulire le caselle prima di ogni esecuzione del test automatico.
Verificare non solo il corpo dell'email, ma anche la funzionalità dei link al suo interno, l'invio da diversi SMTP, la correttezza della visualizzazione per diverse località e formati.

Caratteristiche chiave:

Utilizzo di caselle email "falsi", intercettatori SMTP.
Verifica del contenuto delle email, dei link, delle intestazioni, degli allegati.
Lavoro con API per pulire/verificare la casella prima e dopo il test.

Domande con tranelli.

È possibile testare le notifiche email inviando email a caselle di posta normali in gmail/yandex e controllandole tramite IMAP?

No, spesso lo si fa, ma tale approccio è inaffidabile (dipendenza dal funzionamento del servizio email esterno, filtri spam, assenza di isolamento tra i test, difficoltà di pulizia della casella, non garantita consegna).

È sufficiente controllare solo che l'email sia arrivata?

No, è necessario validare il corpo, gli allegati, la presenza dei link richiesti, il corretto modello linguistico, la corrispondenza delle intestazioni (From/To/Subject), la correttezza della struttura mime.

Nel test non è necessario pulire l'inbox falso tra gli scenari, non succederà nulla di grave?

No! Se non si pulisce l'inbox tra i test, rapidamente ci sarà confusione e sarà impossibile catturare bug. Gli scenari "vedranno" email altrui e i test diventeranno non validi.

Errori comuni e antipattern

Utilizzo di caselle reali, non isolate in CI/CD.
Verifica solo del fatto che l'email sia stata ricevuta, senza esaminare contenuto e allegati.
Mancanza di pulizia dell'inbox tra i test.

Esempio dalla vita

Caso negativo

I test sulle email sono stati costruiti tramite un gmail di test, loggando tramite IMAP, controllando solo che "qualcosa fosse arrivato" nella casella. Le email finivano spesso nello spam, alcune non arrivavano, e dopo l'esecuzione di test paralleli in un inbox analizzare le email è diventato impossibile.

Pro:

Verifica rapida delle notifiche senza un'infrastruttura separata.

Contro:

Nessun isolamento: le email altrui ostacolano l'analisi.
Fallimenti casuali dei test a causa di problemi con la posta esterna.
Non vengono validati allegati, link, modelli.

Caso positivo

Implementazione di Mailtrap, assegnazione di inbox uniche per ciascun caso di test, implementazione di pulizia automatica, validazione del contenuto e degli allegati, orizzonte di attesa, controlli per le lingue.