OTP testen ist der kleine, hartnäckige Teil einer End-to-End-Suite, der einen Einmalcode aus einem Postfach liest und ihn in ein Formular zurücktippt. Er wirkt trivial, bis er unzuverlässig wird, und er wird aus Gründen unzuverlässig, die nichts damit zu tun haben, dass der Code falsch wäre: eine langsame Nachricht, eine ältere Nachricht, die noch im Postfach liegt, ein erneut angeforderter Code, der gedrosselt wurde. Dieser Artikel behandelt, wie dieser Schritt verlässlich wird und wann Sie aufhören sollten, ihn zu automatisieren.
Was eine End-to-End-Suite von einer Code-Nachricht braucht
Eine Code-Nachricht hat eine Aufgabe: ein kurzes Geheimnis von Ihrer Anwendung an einen Ort zu tragen, an dem der Test es lesen kann. Alles Weitere an ihr – Layout, Marke, Fußzeile, Sprache – ist aus Sicht der Suite Verzierung.
Genau diese Ungleichheit macht den Schritt so fehleranfällig. Weil der Test nur eine Handvoll Zeichen braucht, ist es verlockend, sie lose aus der ersten Nachricht zu kratzen, die nahe genug aussieht. Das Ergebnis ist ein Test, der meistens besteht und gelegentlich die falsche Nachricht liest – die teuerste Art von Flackern: selten genug, um abgetan zu werden, und echt genug, um einen wirklichen Fehler zu verbergen.
Welche Nachricht ist die richtige?
Identität, nicht nur Aktualität. Die sicherste Regel ist eine Kombination: Die Nachricht muss an die Adresse gerichtet sein, die dieser Fall angelegt hat, und sie muss die neueste passende Nachricht in diesem Postfach sein.
Beide Hälften verdienen ihren Platz. Der Abgleich auf den Empfänger entfernt Verunreinigung zwischen Tests, weil eine an die Adresse eines anderen Falls gesendete Nachricht die Prüfung nicht erfüllen kann, so neu sie auch ist. Die neueste unter den Treffern zu bevorzugen, behandelt den Fall, dass derselbe Ablauf zweimal ausgelöst wurde, einmal durch eine Wiederholung oder einen früheren Versuch.
Der Abgleich auf den Betreff ist ein nützlicher Verengungsschritt, wenn ein Postfach berechtigterweise mehr als eine Art von Mail enthält – etwa eine Begrüßung und einen Code. Gleichen Sie auf einem stabilen Teil des Betreffs ab und nicht auf der ganzen Zeile, weil sich die Verzierung ändert: Derselbe Betreff mit einer anderen Anrede sollte weiterhin treffen.
Warum werden Tests, die Codes lesen, unzuverlässig?
Vier Ursachen erklären den größten Teil, und jede hat eine andere Abhilfe.
- Ein festes Warten. Eine konstante Zahl von Sekunden zu schlafen ist eine Schätzung, und Schätzungen sind entweder zu kurz, wenn die Nachricht langsam ist, oder verschwenderisch lang, wenn sie schnell ist. Fragen Sie ab, bis die Nachricht erscheint, mit einer Obergrenze, die den Test scheitern lässt, statt den Lauf aufzuhängen.
- Eine veraltete Nachricht. Wird eine Adresse von einem Fall wiederverwendet oder hat ein früherer Versuch eine Nachricht hinterlassen, kann sich eine frische Suche mit altem Inhalt begnügen. Geben Sie jedem Fall eine eigene Adresse, oder notieren Sie wenigstens, was vor dem Start des Ablaufs vorhanden war, und ignorieren Sie Älteres.
- Ein Wiederholungslimit. Code-Abläufe erlauben normalerweise nur wenige erneute Anforderungen in einem kurzen Fenster, was ein bewusster Schutz und kein Mangel ist. Ein Test, der es durch Anfordern eines weiteren Codes wiederholt, wird irgendwann zurückgewiesen und aus dem falschen Grund scheitern; wiederholen Sie, indem Sie das Postfach erneut lesen, statt den Knopf zu drücken.
- Zu eifriges Parsen. Ein Text kann berechtigterweise mehrere Zahlen enthalten – eine Referenz, einen Zeitstempel, einen Preis – und ein Parser, der den ersten Ziffernlauf greift, greift manchmal den falschen. Verankern Sie die Extraktion an der Formulierung um den Code und nicht an den Ziffern allein.
Wann muss ein Mensch im Ablauf bleiben?
Manche Schritte sollten nicht automatisiert werden, und das Gegenteil zu behaupten erzeugt Tests, denen niemand traut.
Ein Mensch ist das richtige Mittel, wenn der Ablauf ein Gerät braucht, das eine Pipeline nicht hat, wenn der Code über einen Kanal kommt, der nicht programmatisch gelesen werden kann, oder wenn die Prüfung eigentlich eine Beurteilung ist, ob die Nachricht gut lesbar ist. Ein einfacherer Fall kommt hinzu: Manche Anbieter raten von automatisierter Registrierung ausdrücklich ab, und eine Suite, die das umgeht, prüft nicht das Produkt, sondern die Umgehung.
Das nützliche Muster ist ein ausdrückliches manuelles Tor, das laut scheitert statt still zu bestehen. Ein Schritt, der sagt, dass ein Mensch nachsehen muss, bevor der Lauf fortgesetzt wird, ist ehrlich; ein Schritt, der es versucht und gelegentlich Erfolg hat, ist es nicht.
Ein Wegwerf-Postfach pro Lauf
Das sauberste Testmittel für diese Arbeit ist ein Postfach, das für den Fall erzeugt wird, der es braucht, und danach verworfen wird. Weil dorthin nie etwas anderes gesendet wurde, ist die neueste Nachricht fast sicher die richtige, und das Frischeproblem verschwindet weitgehend.
Die Seite für temporäre E-Mail erzeugt eine Adresse auf Anforderung: Wählen Sie eine Mail-Domain, geben Sie ihr optional ein Präfix, und ein Postfach erscheint, das das Eintreffende auflistet. Codes werden gesondert hervorgehoben, damit sie kopiert werden können, ohne den ganzen Text zu lesen – bequem, wenn ein Mensch liest, und nützlich zum Nachahmen, wenn Software liest.
Diese Adressen sind Gerüst für einen Testlauf. Sie stehen für niemanden, sie werden mit dem Lauf verworfen, und sie dürfen niemals als echte Identität erfasst oder als Kontaktweg einer Person verwendet werden.
Für Entwickler: Parsing, Frische und Wiederholungsgrenzen
Fünf Entscheidungen machen den Unterschied zwischen einer Suite, die Codes liest, und einer, der man das glaubt.
Geben Sie jedem Fall eine eigene Adresse und lassen Sie die Adresse die Fallidentität tragen, damit eine Nachricht durch Hinsehen zuzuordnen ist und nicht durch den Zeitpunkt.
Fragen Sie mit einer Obergrenze ab und machen Sie die Obergrenze zum Teil der Fehlermeldung. Wenn sie auslöst, sollte der Bericht sagen, welche Adresse gelesen wurde, wie viele Nachrichten darin lagen und welche Betreffzeilen sie hatten. Ohne das startet die nächste Person die Pipeline neu, statt sie zu diagnostizieren.
Parsen Sie defensiv. Nehmen Sie die neueste Übereinstimmung bei Empfänger und erwartetem Betreff und extrahieren Sie den Code dann aus dem Kontext darum. Wird kein Code gefunden, scheitern Sie mit dem Text statt mit einem allgemeinen Zeitfehler.
Deaktivieren Sie niemals ein Ratenlimit, damit ein Test besteht. Das Limit ist Teil des geprüften Verhaltens, und eine Suite, die es abschaltet, beschreibt nicht mehr das Produkt, auf das Ihre Nutzer treffen. Behandeln Sie das Limit stattdessen: Wählen Sie eine Adresse, die kürzlich nicht verwendet wurde, und lesen Sie die vorhandene Nachricht, statt eine neue anzufordern.
Halten Sie den menschlichen Weg am Leben. Für die Fälle, in denen die Automatisierung den Code wirklich nicht lesen kann, dokumentieren Sie den manuellen Schritt und machen Sie ihn in der Ausgabe des Laufs sichtbar, damit eine übersprungene Prüfung nie für eine bestandene gehalten wird.
Der Artikel zum Test von Verifizierungsabläufen behandelt den Ablauf um den Code, und wie temporäre E-Mail funktioniert erklärt, warum eine langsame oder doppelte Nachricht normal und nicht defekt ist.
Nächste Schritte
Suchen Sie den Codeschritt in Ihrer Suite und prüfen Sie die zwei Dinge, die am häufigsten fehlen: ob die Adresse für den Fall einmalig ist und ob die Fehlermeldung es jemand anderem erlauben würde, den Lauf zu diagnostizieren, ohne ihn zu wiederholen. Führen Sie dann denselben Fall mit einer frisch über die Seite für temporäre E-Mail erzeugten Adresse aus und sehen Sie nach, ob die Unzuverlässigkeit verschwindet, die Sie bisher hingenommen haben.