Antwoord.

Geschiedenis van de kwestie:

Het automatiseren van het testen van e-mailmeldingen werd relevant met de ontwikkeling van waarschuwingssystemen (bijvoorbeeld bij registratie, wachtwoordwijzigingen, herinneringen). Aanvankelijk werden dergelijke tests handmatig uitgevoerd en via echte e-mail gecontroleerd (wat extreem inefficiënt en onveilig is in CI/CD). Vervolgens kwamen gespecialiseerde tools (MailHog, Mailtrap, fake SMTP-servers) beschikbaar die automatisering mogelijk en veilig maakten.

Probleem:

De grootste complicaties zijn gerelateerd aan het feit dat e-mail van het systeem "naar buiten" wordt verzonden, wat betekent dat je: a) de verzending moet onderscheppen, b) de inhoud van de e-mail moet verifiëren, c) de correctheid van de verzending moet controleren (de opmaak van de headers, aanwezigheid van bijlagen, links, i18n, correcte correspondentie met gebeurtenissen in het systeem). Er komen complicaties bij voor de snelheid van levering, het schoonmaken van inboxen tussen tests, en het omgaan met SMTP-fouten.

Oplossing:

Gebruik speciale e-mailafvangservices: Mailtrap, MailHog, of geïntegreerde fake SMTP-servers die e-mails niet naar echte post verzenden, maar ze in een test "prullenbak" houden.
Integreer de werking met deze tools via een API-framework of REST-wrapper en implementeer het wachtende op e-mails, het verifiëren van sleutelparameters van de e-mail, validatie van bijlagen, aanwezigheid van correcte links.
Genereer unieke e-mailontvangen voor tests, isoleer testgegevens (bijvoorbeeld door een testdomein te gebruiken) en maak de inboxen schoon voor elke uitvoering van de geautomatiseerde test.
Controleer niet alleen de inhoud van de e-mail, maar ook de werking van de links daarin, verzending vanuit verschillende SMTPs, correctheid van de weergave voor verschillende locales en formaten.

Kernpunten:

Gebruik van "fake" e-mailinboxen, SMTP-afvangers.
Controle van de inhoud van e-mails, links, headers, bijlagen.
Werken met API voor schoonmaken/controleren van de inbox voor en na de test.

Misleidende vragen.

Kan ik e-mailmeldingen testen door berichten naar gewone inboxen in gmail/yandex te sturen en ze via IMAP te controleren?

Nee, dat doen veel mensen, maar zo'n aanpak is onbetrouwbaar (afhankelijk van de werking van externe e-maildiensten, spamfilters, geen isolatie tussen tests, moeilijkheid om de inbox op te schonen, geen garantie voor levering).

Is het voldoende om alleen te controleren of de e-mail is aangekomen?

Nee, het is nodig om de body, bijlagen, aanwezigheid van de nodige links, correcte taalsjablonen, overeenstemming van headers (From/To/Subject), en correctheid van de mime-structuur te valideren.

Is het niet erg om de fake inbox tussen scenario's niet schoon te maken tijdens de test?

Nee! Als je de inbox niet schoonmaakt tussen tests, ontstaat er snel verwarring en is het onmogelijk om bugs te vangen. Scenario's zullen "vreemde" e-mails "zien", en de tests worden ongeldig.

Typische fouten en antipatterns

Gebruik van echte inboxen, niet geïsoleerd in CI/CD.
Alleen controleren van het ontvangen van e-mails, zonder inhoud en bijlagen.
Geen schoonmaak van de inbox tussen tests.

Voorbeeld uit het leven

Negatief geval

De e-mailtests werden uitgevoerd via een test-gmail, ingelogd via IMAP, en controleerden alleen of "iets was aangekomen" in de inbox. E-mails kwamen vaak in de spam, sommige berichten bereikten niet, en na het uitvoeren van parallelle tests in één inbox werd het onmogelijk om e-mails te analyseren.

Voordelen:

Snel notificaties gecontroleerd zonder aparte infrastructuur.

Nadelen:

Geen isolatie: vreemde e-mails verstoren de analyse.
Willekeurige testfouten door problemen met externe e-mail.
Bijlagen, links, sjablonen worden niet gevalideerd.

Positief geval

Mailtrap geïmplementeerd, unieke inboxen toegewezen voor elke testgeval, automatische schoonmaak, inhoudsvalidatie en bijlagen, horizonten van verwachting, validatie per talen geïmplementeerd.