Fehlerinjektion bewirkt, dass sich eine Abhängigkeit absichtlich fehlerhaft verhält, sodass der davon abhängige Code auf die zu erwartenden Fehler getestet werden kann: langsame Antwortzeiten, sporadische 5xx-Fehler, Timeouts, fehlerhafte Codeabschnitte. Sie stellt das kontrollierte, reproduzierbare Ende des Spektrums dar, das im Produktivbetrieb zu Chaos Engineering führt.
Fehler werden an einer für den zu testenden Code nicht einsehbaren Grenze injiziert – beispielsweise an einem simulierten Server, einem Proxy, einer Service-Mesh-Regel oder einem Feature-Flag in der Abhängigkeit selbst. Der Test prüft anschließend das Verhalten: ob Wiederholungsversuche erfolgen und gestoppt werden, ob ein Timeout ausgelöst wird, ob ein Fallback angezeigt wird und ob kein unvollständiger Zustand zurückbleibt.
Zufällige Fehler eignen sich gut für einen Test. Ein Test, der bei jedem vierten Durchlauf fehlschlägt, ist unzuverlässig. Sinnvolle Fehlereinspeisung ist deterministisch – diese Anfrage schlägt fehl, jene ist langsam – oder zumindest so angelegt, dass ein Fehler reproduziert und eine Lösung verifiziert werden kann.
Die Fault Injection API wird mit PUT /faults/v1/config konfiguriert – Latenz, Statuscode, Fehlerrate, fehlerhaftes JSON – und GET /faults/v1/target verhält sich dann genau wie konfiguriert, innerhalb Ihrer eigenen Sandbox.
Diese Seite auf Englisch lesen
Alle Glossarbegriffe · Testtechniken · Alle 39 Mock-REST-APIs
Zuletzt aktualisiert