Warum API-Integrationstests einen expliziten Graphen brauchen
| Die Reihenfolge wird zum Zufall | Tests laufen in der Reihenfolge durch, die der Runner zufällig gewählt hat, und schlagen auf einer anderen Maschine fehl. Dann baut jemand ein Plugin für die Reihenfolge ein, und das Problem ist dauerhaft festgeschrieben. |
| Ein Fehler sieht aus wie zwanzig | Der Anlege-Aufruf schlägt fehl, alles Nachgelagerte schlägt ebenfalls fehl, und Sie sehen einen Bildschirm voller Rot. Den ersten echten Fehler zu finden, wird zur eigentlichen Aufgabe. |
| Parallelisierung ist nicht sicher | Solange nicht klar ist, was wovon abhängt, lässt sich nichts gefahrlos parallel ausführen. Also bleiben die Suites seriell und langsam. |
Den Graphen explizit machen
Die Lösung: Jeder Test deklariert, was er benötigt und was er produziert. Sobald das vorliegt, leitet der Runner daraus eine sichere Reihenfolge ab, unabhängige Zweige laufen parallel, und ein Fehlschlag markiert die davon abhängigen Tests als übersprungen statt als fehlgeschlagen. Aus zwanzig roten Zeilen werden ein Fehler und neunzehn übersprungene Tests – ein völlig anderes Debugging-Erlebnis.
Genau darin unterscheiden sich Endpoint Tests, die jeweils eine Route abdecken, von Integration Tests, die mehrstufige Ketten bilden, in denen eine Antwort in den nächsten Schritt einfließt.
Das Problem der Wertübergabe
Ein Anlege-Aufruf liefert eine ID zurück, die spätere Schritte benötigen. Schreiben Sie sie fest, funktioniert der Test genau einmal. Greifen Sie sie zur Laufzeit ab, reicht die Kette die Daten korrekt weiter. Aufgeschrieben klingt das trivial – und ist trotzdem der mit Abstand häufigste Grund dafür, dass eine Suite, die letzten Monat noch durchlief, heute fehlschlägt.
Aufräumen in einer Kette
Integrationstests erzeugen mehr Zustand als Endpunkt-Tests, und sie erzeugen ihn in einer Abhängigkeitsreihenfolge, an die sich auch das Aufräumen halten muss. Sie können den Kunden nicht vor der Bestellung löschen. Nur ein Aufräumen, das genau an dem hängt, was der jeweilige Lauf erzeugt hat, und das in umgekehrter Abhängigkeitsreihenfolge vorgeht, übersteht parallele Ausführung.
Vier Dinge entscheiden darüber, ob eine API-Suite ihr erstes Jahr übersteht: Sessions, die ablaufen, Werte, die es nur zur Laufzeit gibt, Aufrufe, die voneinander abhängen, und Datensätze, die niemand aufräumt. TestSprite deckt das mit Auto-Authentication, Dynamic Variables, Dependency Chains und Auto-Cleanup ab, beschrieben in der API-Testing-Dokumentation.
Was tun, wenn eine Kette bei Schritt vier fehlschlägt
Der Nutzen deklarierter Abhängigkeiten zeigt sich am deutlichsten daran, wie ein Fehlschlag aussieht – und es lohnt sich, die richtige Lesereihenfolge zu kennen.
Prüfen Sie zuerst, ob der Fehler im Schritt selbst oder in seinen Eingaben liegt. Ein Schritt, der die falsche ID erhalten hat, ist fehlgeschlagen, weil weiter oben etwas Falsches erzeugt wurde – diesen Schritt zu reparieren hieße, das Symptom zu behandeln.
Prüfen Sie zweitens, ob der Fehler auch aus einem sauberen Zustand heraus auftritt. Eine Kette, die einmal funktioniert und beim erneuten Lauf fehlschlägt, sagt Ihnen, dass nicht aufgeräumt wurde – ein anderer Fehler als der, den Sie gerade untersuchen, und oft der wichtigere.
Sehen Sie sich drittens erst dann den Endpunkt selbst an. Meistens steckte die interessante Information bereits in den ersten beiden Prüfungen – und genau deshalb kostet eine flache Liste roter Zeilen beim Debuggen so viel mehr als ein Graph mit einem Fehler und neunzehn übersprungenen Tests.
Halten Sie die Ketten kurz
Eine Kette aus zwölf Schritten, die bei Schritt neun fehlschlägt, ist schwer zu diagnostizieren und langsam erneut auszuführen. Drei bis fünf Schritte, die eine Nutzerabsicht abdecken, sind die Größe, die nützlich bleibt. Lange Ketten bedeuten meist, dass zwei Journeys zusammengelegt wurden.
Erste Schritte
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Wenn Sie nichts installieren möchten, erledigt das Dashboard dasselbe. Alles Weitere, was die Kommandozeile kann, finden Sie im CLI-Repository.
Verbinden Sie das Repository über das Dashboard, dann starten Testläufe aus dem Deployment, das Sie ohnehin erzeugen – oder fügen Sie stattdessen einen Schritt in Ihren eigenen Workflow ein.
Wie TestSprite den Graphen explizit macht
Jeder Testfall deklariert, was er benötigt und was er produziert, und Dependency Chains leiten daraus eine sichere Ausführungsreihenfolge ab. Unabhängige Zweige laufen parallel, und wenn etwas fehlschlägt, werden die davon abhängigen Tests als übersprungen statt als fehlgeschlagen markiert – aus zwanzig roten Zeilen werden so ein Fehler und neunzehn übersprungene Tests.
Dynamic Variables übernehmen die Wertübergabe, sodass eine Kette die ID weiterreicht, die ein Anlege-Aufruf zurückgegeben hat, statt einer Zahl, die jemand hineinkopiert hat. Auto-Cleanup entfernt das, was der jeweilige Lauf erzeugt hat, in umgekehrter Abhängigkeitsreihenfolge – und genau das macht parallele Läufe sicher.
Der Nutzen zeigt sich beim ersten Mal, wenn eine Kette bricht. Sie bekommen einen einzigen Fehler, der die Abweichung benennt, statt eines Bildschirms voller Rot, den Sie durchlesen müssen – das ist der Unterschied zwischen fünf Minuten Diagnose und einem ganzen Nachmittag.
Worin unterscheidet sich das von End-to-End-Tests?
End-to-End bedeutet in der Regel: über die Oberfläche. API-Integrationstests durchlaufen dieselben Journeys auf Service-Ebene – schneller und präziser darin, wo ein Fehler aufgetreten ist.
Sollten Integrationstests echte Abhängigkeiten verwenden?
Beim Integrationstesten ja, genau darum geht es. Das System zu mocken, mit dem integriert wird, beantwortet eine andere Frage.
Wie gehen wir mit Testdaten zwischen den Schritten um?
Greifen Sie ab, was jeder Schritt produziert, und reichen Sie es weiter. Gemeinsam genutzte Seed-Daten sind bequem – bis zwei Ketten denselben Datensatz anfassen.
Was ist mit Drittanbieter-Diensten in einer Kette?
Nutzen Sie deren Sandbox, wo es eine gibt. Wo keine existiert, isolieren Sie diesen Schritt und akzeptieren Sie, dass die Kette dort eine Grenze hat.
Wie viele Integrationstests brauchen wir?
Einen pro User Journey, die zählt, nicht einen pro Endpunkt-Kombination. Die Kombinationen sind unendlich, die Journeys nicht.
Deklarieren Sie den Graphen – oder debuggen Sie ihn für immer.
Bei API-Integrationstests geht es um Abläufe, und Abläufe haben einen Abhängigkeitsgraphen. Wenn jeder Test deklariert, was er benötigt und was er produziert, bekommen Sie eine sichere Reihenfolge, Parallelität und lesbare Fehler. Greifen Sie Werte zur Laufzeit ab, statt sie fest zu verdrahten, und halten Sie die Ketten kurz.