Odpowiedź.

Historia zagadnienia:

Automatyzacja testowania powiadomień e-mail stała się istotna wraz z rozwojem systemów powiadamiania (np. podczas rejestracji, zmiany hasła, przypomnienia). Początkowo takie testy były przeprowadzane ręcznie i weryfikowane za pośrednictwem rzeczywistej poczty (co jest niezwykle nieefektywne i niebezpieczne w CI/CD). Następnie pojawiły się specjalistyczne narzędzia (MailHog, Mailtrap, fałszywe serwery SMTP), które umożliwiły automatyzację w sposób bezpieczny.

Problem:

Główne trudności związane są z tym, że e-mail jest wysyłany z systemu "na zewnątrz", co oznacza, że musimy: a) przechwycić wysyłkę, b) upewnić się o zawartości wiadomości, c) sprawdzić poprawność wysyłki (format nagłówków, obecność załączników, linki, i18n, poprawność podziału na zdarzenia w systemie). Dodawane są trudności związane z czasem dostawy, czyszczeniem skrzynek między testami, obsługą błędów SMTP.

Rozwiązanie:

Użyć specjalnych serwisów do przechwytywania wiadomości: Mailtrap, MailHog lub zintegrowane fałszywe serwery SMTP, które nie dostarczają wiadomości do rzeczywistej poczty, a przechowują je w testowej "koszyku".
Zintegrować pracę z tymi narzędziami za pośrednictwem frameworka API lub opakowań REST i zrealizować oczekiwanie na wiadomości, weryfikację kluczowych parametrów wiadomości, walidację załączników, obecność poprawnych linków.
Generować unikalne adresy e-mail do testów, izolować dane testowe (np. używać domeny testowej) i czyścić skrzynki przed każdym uruchomieniem testu automatycznego.
Sprawdzać nie tylko treść wiadomości, ale także funkcjonalność linków w niej, wysyłkę z różnych SMTP, poprawność wyświetlania dla różnych lokalizacji i formatów.

Kluczowe cechy:

Użycie "fałszywych" skrzynek e-mail, przechwytywaczy SMTP.
Weryfikacja zawartości wiadomości, linków, nagłówków, załączników.
Praca z API w celu czyszczenia/weryfikacji skrzynki przed i po teście.

Pytania z podchwytliwych sytuacji.

Czy można testować powiadomienia e-mail, wysyłając wiadomości na zwykłe skrzynki pocztowe w gmail/yandex i sprawdzając je przez IMAP?

Nie, tak często się robi, ale takie podejście jest niewiarygodne (zależność od działania zewnętrznego serwisu e-mail, filtry spamowe, brak izolacji między testami, trudność w czyszczeniu skrzynki, brak gwarancji dostawy).

Czy wystarczy tylko sprawdzić, że wiadomość dotarła?

Nie, należy walidować treść, załączniki, obecność potrzebnych linków, poprawny szablon językowy, zgodność nagłówków (From/To/Subject), poprawność struktury mime.

Czy można nie czyścić fałszywej skrzynki między scenariuszami, nic złego się nie wydarzy?

Nie! Jeśli nie czyścić skrzynki między testami, szybko powstanie chaos i trudno będzie wyłapać błędy. Scenariusze będą "widzieć" obce wiadomości, a testy staną się nieważne.

Typowe błędy i antywzorce

Użycie rzeczywistych skrzynek, nieizolowanych w CI/CD.
Weryfikacja tylko faktu otrzymania wiadomości, bez treści i załączników.
Brak czyszczenia skrzynki między testami.

Przykład z życia

Negatywny przypadek

Testy e-mail zbudowane za pomocą testowego gmail, logując się przez IMAP, sprawdzali tylko, że "coś przyszło" do skrzynki. Poczta często wpadała do spamu, część wiadomości nie docierała, a po uruchomieniu równoległych testów w jednym inbox analizy wiadomości stały się niemożliwe.

Zalety:

Szybko uruchomiliśmy weryfikację powiadomień bez oddzielnej infrastruktury.

Wady:

Brak izolacji: obce wiadomości komplikują analizę.
Losowe błędy testów z powodu problemów z zewnętrzną pocztą.
Nie walidowane załączniki, linki, szablony.

Pozytywny przypadek

Wdrożono Mailtrap, wydzielono unikalne skrzynki dla każdego przypadku testowego, zrealizowano automatyczne czyszczenie, walidację zawartości i załączników, horyzont oczekiwania, weryfikację językową.