Fehlerpfade und Timeouts ausgehender Aufrufe testen

Ziel

Den Code, der ausgeführt wird, wenn eine Abhängigkeit fehlschlägt, ebenso gut testen wie den Happy Path. Dieser Code läuft in der Entwicklung selten und während Vorfällen ständig — genau dann ist es am wenigsten tragbar, zu entdecken, dass er nie funktioniert hat.

Voraussetzungen

Ausgehende Aufrufe laufen über einen injizierbaren Client oder Adapter; Timeouts sind je Aufruf konfigurierbar; das Testframework kann Exceptions sowie Log- oder Metrikausgaben prüfen.

Schritte

1. Für jede ausgehende Abhängigkeit die Fehlerklassen auflisten: Verbindung verweigert, Verbindung zurückgesetzt, Timeout beim Verbindungsaufbau, Timeout beim Lesen, HTTP 5xx, HTTP 429 mit Retry-After, fehlerhafter Body, abgeschnittener Body, langsamer Body. Jede wird zu mindestens einem benannten Test.
2. Auf Unit-Ebene den Fehler mit einem Test-Double auslösen. Pythons unittest.mock dokumentiert side_effect: Eine Exception wird beim Aufruf des Mocks ausgelöst, und ein Iterable liefert aufeinanderfolgende Ergebnisse, sodass „schlägt zweimal fehl, gelingt dann“ eine Zeile Einrichtung ist.
3. Das vom Design zugesagte Verhalten prüfen, nicht den Exception-Text: Die aufrufende Stelle bricht nach N Versuchen ab, wartet mit Backoff und Jitter, löst einen typisierten Fehler aus, zeichnet eine Metrik auf, hinterlässt keinen unvollständigen Schreibvorgang und gibt die Verbindung an den Pool zurück.
4. Das Timeout selbst mit einer gefälschten Uhr oder einem nie antwortenden Server testen: Ein lauschender Socket, der annimmt und dann schweigt, prüft das Read-Timeout; eine nicht routbare Adresse prüft das Connect-Timeout. Das getestete Timeout klein halten, damit der Test schnell bleibt.
5. Auf Integrationsebene einen fehlerinjizierenden Proxy zwischen den Dienst und seine Abhängigkeit setzen. Die README von Toxiproxy beschreibt Toxics, die Latenz mit Jitter hinzufügen, Bandbreite begrenzen, Daten stoppen und nach einer Verzögerung schliessen (timeout), einen TCP-Reset simulieren (reset_peer) oder das Schliessen verzögern (slow_close), jeweils über eine HTTP-API schaltbar, sodass ein Test einen Fehler aktivieren, das Szenario ausführen und ihn wieder deaktivieren kann.
6. Das Aufräumen nach einem Fehler testen: Eine Anfrage, die ein Timeout hatte, darf keine Pool-Verbindung oder ein Lock behalten; nach dem Test die Pool-Statistiken lesen.
7. Für jeden vergangenen Vorfall einen Test hinzufügen, der seinen Auslöser reproduziert, und ihn behalten.

Erwartetes Ergebnis

Jede Fehlerklasse hat einen benannten Test; das Ändern eines Timeouts oder einer Retry-Policy lässt einen Test scheitern, statt eine betreibende Person zu überraschen.

Grenzen und Prüfbasis

Mocks testen die Logik der aufrufenden Stelle, nicht das Verhalten der echten Bibliothek unter einem echten Timeout; mindestens einen Test je Client mit einem echten Socket behalten. Proxy-basierte Tests sind langsamer und brauchen Orchestrierung in der CI. Dies ist ein vorgeschlagenes Vorgehen; es wird keine Messung behauptet.