E-Mail im Test abzufangen heißt, Mail nicht länger als etwas zu behandeln, das die Maschine verlässt. Statt einen Build über einen öffentlichen Anbieter senden und anschließend ein Postfach in der Außenwelt abfragen zu lassen, wird die Anwendung auf einen empfangenden Endpunkt auf der Build-Maschine gerichtet, und der Test liest, was übergeben wurde. Das Ergebnis ist schneller, offline fähig und unempfindlich gegen die Störungen eines Anbieters, die sonst eine grüne Suite rot machen.
Warum eine Pipeline nicht von einem Mailanbieter abhängen sollte
Ein Test, der echte Mail über einen echten Dienst versendet, hat alles Brüchige dieses Dienstes in sein eigenes Ergebnis importiert. Die Authentifizierung kann ablaufen, Kontingente können erschöpft sein, der Anbieter kann kurz nicht erreichbar sein – und keine dieser Lagen sagt etwas über Ihren Code aus. Schlimmer: Sie sind von den Fehlern, die Sie tatsächlich fangen wollen, nicht zu unterscheiden, und so lernt das Team, die Pipeline neu zu starten statt sie zu lesen.
Es gibt einen zweiten Kostenpunkt, der leicht übersehen wird: Eine Pipeline, die echte Mail versendet, muss gesagt bekommen, wohin. Ist dieses Ziel eine echte Adresse, liefert jeder Lauf Testverkehr an jemanden. Den Build auf einen lokalen Endpunkt zu richten, beseitigt die Frage vollständig, weil nichts das Netz verlässt.
Wie funktioniert ein lokaler Aufnahme-Endpunkt?
Der Mechanismus ist derselbe, den jeder Mailserver nutzt. Ihre Anwendung wird für die Dauer des Testlaufs mit Host und Port eines Mailservers konfiguriert. Dieser Host ist die Loopback-Schnittstelle und der Port derjenige, den das Testgerüst für diesen Lauf gewählt hat, es muss also kein Konfigurationswert als Tatsache über die Welt behauptet werden.
Sobald die Anwendung die Nachricht übergibt, nimmt der Aufnahme-Endpunkt sie an, hält sie im Speicher oder schreibt sie in eine Datei und stellt sie dem Test zur Verfügung. Weitergeleitet wird nichts.
Diese Form bringt drei Eigenschaften mit, die Prüfungen verlässlich machen:
- Die Nachricht existiert, bevor der Test nach ihr sucht, weil die Übergabe synchron ist; es gibt also keine Abfrageschleife, die man falsch machen könnte.
- Der Inhalt ist exakt, einschließlich Kopfzeilen und Kodierung, weil unterwegs nichts umgeschrieben wurde.
- Die Nachricht kann beliebig oft erneut gelesen werden, weil sie gespeichert und nicht verbraucht wird.
Was steckt tatsächlich in einer aufgefangenen Nachricht?
Mehr als der Text – und in den zusätzlichen Teilen liegen die nützlichen Prüfungen. Eine aufgefangene Nachricht trägt die Umschlaginformationen aus der Übergabe zusammen mit der Nachricht selbst, ein Test kann also prüfen, von wem die Nachricht zu stammen behauptet, an welche Adresse sie ging, die Betreffzeile, den Inhaltstyp und den Text in der Form, in der Ihre Anwendung ihn erzeugt hat.
Das ist wichtig, weil nicht die Zustellung das Prüfobjekt ist, sondern der Inhalt. Eine Suite, die nur bestätigt, dass eine Nachricht angenommen wurde, besteht fröhlich weiter, während die Vorlage einen leeren Namen rendert oder der Link auf die falsche Umgebung zeigt.
Sollte ein scheiternder Test die Rohmail behalten?
Ja, und zwar absichtlich und nicht zufällig. Wenn eine Prüfung des Textes scheitert, ist das einzelne nützlichste Artefakt die Nachricht, wie sie tatsächlich erzeugt wurde. Ohne sie ist der nächste Schritt meist, den Fehler lokal von Hand nachzustellen – genau die manuelle Arbeit, die der Aufnahme-Endpunkt beseitigen sollte.
Zwei Gewohnheiten machen das Artefakt nützlich. Hängen Sie es an den scheiternden Lauf statt an einen geteilten Ort, damit nebenläufige Läufe einander nicht überschreiben. Und behandeln Sie es als Testdaten, wenn es gespeichert wird: Eine aufgefangene Nachricht kann Adressen und erzeugte Werte aus dem Lauf enthalten und sollte nach demselben kurzen Zeitplan aufbewahrt werden wie die übrige Ausgabe des Laufs. So verwendete Adressen existieren für Prüfungen und niemals als echte Identitäten.
Wann Sie stattdessen ein echtes Postfach brauchen
Eine lokale Aufnahme kann Fragen nicht beantworten, die die Außenwelt betreffen. Muss ein Test beweisen, dass eine Nachricht einen tatsächlichen Zustellweg übersteht, oder dass das System eines Dritten darauf reagiert, dann muss etwas die Maschine verlassen.
Für diese Fälle genügt oft ein Wegwerf-Postfach: eine für den Lauf erzeugte Adresse, einmal gelesen, verworfen. Die Seite für temporäre E-Mail erzeugt eines auf Anforderung, und weil niemand die Adresse registriert hat, startet das Postfach leer und enthält nichts außer dem Verkehr, den der Test ausgelöst hat. Halten Sie den Unterschied im Kopf sauber: Die lokale Aufnahme dient Prüfungen darüber, was Ihre Anwendung versendet, und ein echtes Postfach Prüfungen darüber, was ankommt.
Für Entwickler: Ports, Parallelität und Prüfungen
Vier Entscheidungen bestimmen, ob diese Anordnung langweilig bleibt.
Den Aufnahme-Endpunkt ausschließlich an die Loopback-Schnittstelle zu binden, steht an erster Stelle. Das begrenzt die Angriffsfläche und macht offensichtlich, dass der Endpunkt kein Maildienst für irgendetwas außerhalb des Laufs ist. Lassen Sie den Port aus der Umgebung kommen statt aus einer Konstante, damit zwei Läufe auf einer Maschine nicht kollidieren.
Läufe zu trennen, steht an zweiter Stelle. Geben Sie jedem Lauf einen eigenen Endpunktprozess oder wenigstens einen eigenen Speicher und jedem Fall eine eigene Empfängeradresse. Eine geteilte Warteschlange, die mehrere Tests parallel lesen, erzeugt die ärgerlichste Fehlerklasse überhaupt: einen Test, der allein besteht und in einer vollständigen Pipeline scheitert.
Inhalt statt verstrichener Zeit zu prüfen, steht an dritter Stelle. Weil die Übergabe synchron ist, gibt es nichts zu warten; ein Warten in dieser Art Test ist ein Zeichen dafür, dass über die falsche Schnittstelle geprüft wird.
Laut zu scheitern, steht an vierter Stelle. Wenn eine Prüfung einer Nachricht scheitert, geben Sie den verglichenen Teil aus oder hängen Sie ihn an. Ein Test, der nur eine Abweichung meldet, ohne die gelesene Nachricht zu zeigen, schickt die nächste Person zurück zur manuellen Nachstellung.
Wenn Ihr Aufnahmeweg Tests speist, die kurze Codes statt Texte lesen, deckt der Artikel zum OTP-Test in End-to-End-Suiten die Ausleseseite ab, und der Artikel über das Catch-all-Postfach behandelt, was zu tun ist, wenn eine Umgebung wirklich eine ganze Domain statt eines einzelnen Endpunkts braucht.
Nächste Schritte
Suchen Sie den einen Test in Ihrer Suite, der Mail über einen Anbieter versendet, und zählen Sie, wie oft er aus Gründen scheiterte, die nichts mit der geprüften Änderung zu tun hatten. Geben Sie ihm dann für einen einzigen Lauf einen lokalen Endpunkt und vergleichen Sie. Behalten Sie den öffentlichen Anbieter für alles, was wirklich das offene Internet braucht; der Rest gehört auf die Maschine, die die Tests ausführt. Wenn Sie für den einen oder anderen Fall doch eine echte Adresse benötigen, erzeugt die Seite für temporäre E-Mail eine in wenigen Sekunden.