Ein HTTP-Fehler bleibt eine HTTP-Antwort.

Ein Panel lädt nicht, der Test wartet auf requestfailed. Nichts kommt: Der Server hat eine HTTP-Fehlerantwort geliefert. Das fehlende Ereignis belegt keinen Produkterfolg. Die Prüfung fragte nach der falschen Grenze.

Dieser Leitfaden nutzt Playwright-Netzwerkdokumentation und Page mit lokalen erfundenen Requests: kontrollierte 503-Antwort und absichtlicher Routenabbruch. Kein Kundenendpunkt oder echter Ausfall. Status und Transport bleiben getrennt.

Lies den Status ausdrücklich

Die API beschreibt request, response und requestfinished bei abgeschlossenen Requests. HTTP-Fehler sind Antworten, keine requestfailed-Ereignisse. Transport kann enden, während das Produktversprechen scheitert.

const pending = page.waitForResponse(response =>
  response.url().endsWith('/demo-unavailable')
);
await page.getByRole('button', { name: 'Load demo panel' }).click();
const response = await pending;
expect(response.status()).toBe(503);
await expect(page.getByRole('status')).toHaveText('Demo service unavailable');

Lokaler Button und Server mit kontrolliertem Status sind nötig. Die UI meldet den Fehler. 503 passt zum negativen Beispiel, nicht als akzeptierter Ausgang eines echten Erfolgsfalls.

Registriere die Wartebedingung vor der Aktion. Wähle Endpunkt und Identität aus dem Vertrag. Ein breiter Listener könnte fremde Antworten als Beleg verwenden.

Nutze requestfailed für seine Frage

Es beschreibt fehlenden normalen Antwortabschluss, etwa einen Transportfehler. Das zweite Beispiel nutzt route.abort(). Geprüft werden gewählte URL und Fehlerbeschreibung, kein browserübergreifend konstanter Wortlaut.

Abbruch ist keine serverseitige 503-Antwort. Halte Namen und Erwartungen getrennt. Wenn beide einen Wiederholungsweg verlangen, prüfe ihn in jeder Einrichtung ohne Vermischen der Ursachen.

Ein Ereignis bestimmt keine genaue Produktionsursache. Es hilft, identifiziert aber nicht allein Server, Netzwerksprung oder Richtlinie. Kombiniere passende Belege im erlaubten System.

Verwechsle Abschluss und Geschäftserfolg nicht

Eine Antwort kann gültigen Status und falschen Datensatz oder Fehlerinhalt haben. Status ist nur Vertragsbestandteil. Prüfe Inhalte und UI-Erwartung, ohne die Demoaussage zu erweitern.

Der Server zählt eine abgeschlossene 503, ohne requestfailed für diese URL. Der Abbruch erzeugt requestfailed. Das prüft Ereignissemantik, misst keine Zuverlässigkeit und reproduziert keinen externen Ausfall.

Wiederhole Klicks nicht wegen eines fehlenden Ereignisses. Der Server kann die Operation bereits erhalten haben; Wiederholung dupliziert sie. Bestimme Grenze und erlaubten Wiederholungsweg zuerst.

Halte die Fehlerbegriffe konkret

Notiere Endpunkt, Status oder Ereignis, UI-Ergebnis und offene Fragen. Das hilft mehr als Netzwerk fehlgeschlagen. Schütze private URLs und Payloads vor dem Teilen.

AnyTest beschreibt prüfbare Tests nach Erkundung. Frage nach richtigem Ereignis und geprüftem Wiederherstellungszustand. Keine AnyTest-Netzwerkfunktion wird behauptet. Trenne erfolglose Antwort und fehlenden Antwortabschluss.