Ein automatisierter E‑Mail‑Test benötigt mehr als nur eine Posteingangsadresse. Er benötigt einen Vertrag, der beschreibt, welche Nachricht zum Lauf gehört, wie lange gewartet werden soll und welche Beweise bei einem Fehlschlag des Tests aufbewahrt werden.
Geben Sie jedem Lauf einen Korrelationsdatensatz
Speichern Sie einen Testlauf‑Identifier, synthetischen Empfänger, Auslösezeit und den erwarteten Nachrichtenzweck. Wo Ihre Anwendung dies unterstützt, fügen Sie einen nicht‑sensiblen Korrelationsmarker in die Testnachricht ein. Vergleichen Sie nicht nur den Betreff: eine alte Nachricht mit demselben Betreff kann sonst einen fehlgeschlagenen Lauf als erfolgreich erscheinen lassen.
Warten Sie innerhalb eines expliziten Budgets
create test context
trigger the application action
until the test deadline:
read messages using the provider's documented API
accept only a message matching this run
wait using bounded backoff if no match exists
report matched, timed out, or provider errorDies ist Pseudocode, kein CleanTempMail‑API‑Beispiel. Verwenden Sie die aktuelle API‑Dokumentation für Authentifizierung, Endpunkte und Anforderungsgrenzen. Beachten Sie die Wiederholungsanweisungen und brechen Sie die verbleibende Arbeit ab, wenn der Job endet.
Verhalten nach Empfang prüfen
In einer von Ihnen kontrollierten Testumgebung bestätigen Sie, dass die Verifizierungsaktion den beabsichtigten Kontozustand erzeugt. Das bloße Empfangen einer Nachricht ist kein Beweis dafür, dass ihr Link funktioniert. Halten Sie Authentifizierungstoken und Nachrichteninhalte aus der normalen CI‑Ausgabe heraus.
Fehler diagnostizierbar machen
Unterscheiden Sie Anwendungs‑Sende‑Fehler, keine passende Nachricht vor Ablauf der Frist, Anbieter‑Nichtverfügbarkeit und Assertion‑Fehler. Bewahren Sie bereinigte Zeitstempel und Identifier auf, entfernen Sie dann synthetische Konten und Mail‑Artefakte gemäß der Test‑Aufbewahrungsrichtlinie des Teams.