Ein fehlerhafter Test liefert für denselben Code unterschiedliche Ergebnisse. Häufige Ursachen beim API-Testing sind Timing-Probleme – beispielsweise das Ausführen einer Assertion, bevor ein asynchroner Prozess abgeschlossen ist –, gemeinsam genutzte Zustände zwischen Tests, Datenreste aus früheren Testläufen, echte Netzwerkaufrufe, nicht initialisierte Zufallsdaten und die Abhängigkeit vom aktuellen Datum oder der Zeitzone.
Instabilität wird diagnostiziert, indem derselbe Commit so lange wiederholt wird, bis der Fehler auftritt, und die Unterschiede verglichen werden. Sie lässt sich beheben, indem die Fehlerquelle beseitigt wird: Warten auf eine Bedingung anstatt auf eine feste Zeit, jedem Test eigene Daten zuweisen, Generatoren initialisieren, Uhren einfrieren und aktive Abhängigkeiten durch simulierte oder selbstkontrollierte Sandbox-Abhängigkeiten ersetzen.
Automatische Wiederholungsversuche beheben keinen fehlerhaften Test. Sie verschleiern jedoch das Symptom und lassen die Ursache bestehen; außerdem verbergen sie echte, sporadisch auftretende Fehler im Produkt – eine Race Condition sieht genauso aus wie ein fehlerhafter Test. Quarantäne und Behebung sind besser als Wiederholungsversuche, bei denen man das Problem ignoriert.
POST /protocol/v1/jobs gibt den Statuscode 202 zurück, und der Job wird bei jeder Abfrage von GET /protocol/v1/jobs/{id} fortgesetzt – eine gute Gelegenheit, das Warten auf eine Bedingung anstatt des Wartens zu üben. Setzen Sie die Sandbox zwischen den Ausführungen zurück, um Datenlecks zu vermeiden.
Diese Seite auf Englisch lesen
Alle Glossarbegriffe · Testtechniken · Alle 39 Mock-REST-APIs
Zuletzt aktualisiert