Simulieren Sie die Abhängigkeit. Benennen Sie die Grenze.

Ein Lieferangebot schlägt während einer Freigabeprüfung fehl. Ist die Checkout-Benutzeroberfläche defekt, ist der Angebotsanbieter nicht verfügbar oder hat die Testumgebung ihre Anmeldeinformationen verloren? Ein rotes Ergebnis repräsentiert nun mehrere Systeme. Eine kontrollierte Reaktion kann Ihnen bei der Untersuchung der Benutzeroberfläche helfen, verändert jedoch die Bedeutung des Ergebnisses.

In diesem Leitfaden wird anhand eines kleinen Lieferangebotsbildschirms gezeigt, wie eine Abhängigkeit simuliert und die Beweise ehrlich gekennzeichnet werden. Es basiert auf Playwrights Mocking-Guide und Netzwerkdokumentation. Bei dem hier gezeigten Bildschirm handelt es sich um eine lokale, anschauliche Demo mit erfundenen Versandoptionen, nicht um einen Kunden-Workflow oder einen Live-Service.

Entscheiden Sie, welche Frage der Test beantwortet

Die UI-Frage lautet, ob die Seite einen zurückgegebenen Preis anzeigt, eine leere Liste verarbeitet und ein nicht verfügbares Angebot erklärt. Die Integrationsfrage besteht darin, ob der reale Dienst die Anfrage akzeptiert und die vereinbarte Antwortform zurückgibt. Sie können diese separat testen und neben einer deterministischen UI-Suite einen kleineren Real-Service-Check durchführen.

Nennen Sie den verspotteten Pfad nicht den vollständigen End-to-End-Beweis für den Dienst. Sein Wert ist enger: Ihr Frontend empfängt bekannte Daten und verhält sich korrekt. Das ist ein nützlicher Beweis, wenn er richtig benannt wird. Eine grün simulierte Abhängigkeit kann Ihnen nicht sagen, ob ein Anbieter seine Anmeldeinformationen geändert, Ihre Nutzlast abgelehnt oder die Bereitstellung Ihrer Region eingestellt hat.

Installieren Sie die Route, bevor die Anfrage erfolgt

In dieser anschaulichen App wird beim Laden der Angebotsseite /api/delivery-quote angefordert. Das Beispiel fängt genau diesen Pfad ab und gibt ein kontrolliertes JSON-Objekt zurück. Registrieren Sie den Handler vor der Navigation, damit die erste Anfrage nicht dem beabsichtigten Setup entgehen kann.

await page.route('**/api/delivery-quote', async route => {
  await route.fulfill({
    status: 200,
    contentType: 'application/json',
    body: JSON.stringify({ label: 'Standard', price: '4.00' })
  });
});
await page.goto('/delivery-quote');
await expect(page.getByRole('status')).toHaveText('Standard: 4.00');

Verwenden Sie für diese relative Navigation eine konfigurierte Staging-Basis-URL. Die Antwortform ist unser Demovertrag, keine universelle Liefer-API. Ein echter Test sollte Ihr dokumentiertes Schema und Ihre Währungsregeln verwenden. Passen Sie nur den Endpunkt an, den Sie steuern möchten. Das Abfangen des gesamten Datenverkehrs kann nicht zusammenhängende Fehler verbergen.

Die Route API von Playwright unterscheidet zwischen der Erfüllung einer Anfrage und dem Abrufen einer echten Antwort und deren Änderung. Im obigen Beispiel wird der Upstream-Angebotsdienst nicht aufgerufen. Ein route.fetch()-Beispiel hätte eine andere Grenze, da es immer noch von der Upstream-Antwort abhängt.

Testen Sie Fehlerzustände, ohne auf einen Anbieterausfall warten zu müssen

Geben Sie in einem zweiten Test eine 503-Antwort zurück und überprüfen Sie dann, ob auf der Seite erklärt wird, dass das Angebot nicht verfügbar ist, und dass die beabsichtigte nächste Aktion angeboten wird. Ein dritter Test kann ein erfolgreiches leeres Ergebnis liefern, wenn dies ein aussagekräftiger Zustand in Ihrem Vertrag ist. Halten Sie jedes Setup klein und explizit.

await page.route('**/api/delivery-quote', route =>
  route.fulfill({ status: 503, body: 'Unavailable' })
);
await page.goto('/delivery-quote');
await expect(page.getByRole('alert')).toHaveText('Quote unavailable');

Diese Snippets gehören zu separaten Testfällen. Die App muss dieses Warnverhalten implementieren. Dies ist kein Matcher, der es erstellt. Stellen Sie sicher, dass ein Benutzer einen sicheren nächsten Schritt hat und nicht nur, dass roter Text angezeigt wird. Fälschen Sie niemals eine abgeschlossene Zahlung, um zu beweisen, dass eine echte Zahlung funktioniert.

Achten Sie auf die blinden Flecken

Ein Servicemitarbeiter kann Anfragen abfangen, bevor die Seite oder das Kontextrouting von Playwright sie erkennt. In der Netzwerkdokumentation wird empfohlen, Servicemitarbeiter zu blockieren, wenn beim nativen Routing erwartete Anforderungen fehlen. Wählen Sie diese Einstellung bewusst in Ihrer kontrollierten Testkonfiguration; Wenn Sie es ändern, kann das Verhalten entfernt werden, das Sie sonst testen müssten.

Das Browser-Kontext-Routing kann Seiten und Popups innerhalb des Kontexts abdecken, wohingegen eine Regel auf Seitenebene einen engeren Geltungsbereich hat. Entscheiden Sie, welches Verhalten Sie benötigen, anstatt jede Regel auf den weitesten Bereich auszuweiten. Behalten Sie die Routenhandler und Daten des Tests innerhalb seines Lebenszyklus.

Aufgezeichnete HTTP-Archive können ebenfalls Datenverkehr wiedergeben, die Aufzeichnungen können jedoch vertrauliche Header, Cookies und Antwortdaten enthalten. Überprüfen und bereinigen Sie eine Aufnahme, bevor Sie sie speichern. Für diesen Fall eines einfachen Zitats ist eine handverfasste Antwort einfacher zu prüfen als ein großes erfasstes Archiv.

Geben Sie dem Beweis einen Namen, der im Dashboard erhalten bleibt

Verwenden Sie einen Testtitel, z. B. die Benutzeroberfläche eines Lieferangebots oder eine vorgetäuschte Antwort des Anbieters. Geben Sie in den Überprüfungsnotizen den kontrollierten Endpunkt, die Vertragsversion und den separaten Real-Service-Check an. Ein Teamkollege sollte nicht den Routencode überprüfen müssen, um festzustellen, dass der Anbieter abwesend ist.

AnyTest beschreibt URL-gesteuerte Erkundungen und testet die Überprüfung durch Menschen. Wenden Sie dieselbe Beweisfrage auf jeden vorgeschlagenen Ablauf an: Welche Abhängigkeiten waren real, welche wurden kontrolliert und was stellt ein Durchgang fest? Dieses Handbuch erhebt keinen Anspruch auf eine bestimmte Spottschnittstelle innerhalb von AnyTest.

Für ein kleines QA-Team ist der Vorteil ein klarerer Diagnosepfad und eine bewusste Fehlerzustandsabdeckung. Für eine entwicklereigene Testsuite gilt dasselbe: Sorgen Sie für wiederholbare UI-Prüfungen, halten Sie die Integrationsgrenze sichtbar und lassen Sie nicht zu, dass eine praktische simulierte Abhängigkeit zu einem größeren Versprechen wird, als der Test unterstützen kann.