Route fallback erhält die Handlerkette.
Prüfen Sie die Registrierungsreihenfolge vor der Weiterleitung eines abgefangenen Requests.

Übersetzte Ausgabe. Technische Kennungen bleiben in ihrer ursprünglichen Form.

Ein lokaler Test registriert eine Antwortfixture, dann einen Beobachter für denselben Endpunkt. Der Beobachter ruft continue() auf. Die Fixture läuft nicht; der Request erreicht den Server. Die Methode zur Übergabe bestimmt das gemeinsame Verhalten.
Die Route-API beschreibt umgekehrte Registrierungsreihenfolge. Der letzte passende Handler läuft zuerst. fallback() übergibt an den nächsten passenden Handler. continue() sendet sofort ins Netzwerk und überspringt andere passende Handler.
Die Kette zuerst festlegen
Für /demo-value registrieren wir die Fixture vor dem Beobachter. Der Beobachter läuft zuerst, danach die Fixture. Ihre kontrollierte Antwort soll keinen Aufruf des lokalen Serverendpunkts erzeugen.
const order: string[] = [];
await page.route('**/demo-value', async route => {
order.push('fixture');
await route.fulfill({ status: 200, body: 'fixture value' });
});
await page.route('**/demo-value', async route => {
order.push('observer');
await route.fallback();
});Das Beispiel setzt eine lokale Seite und einen folgenden Request voraus. Prüfen Sie Antworttext und protokollierte Reihenfolge. Der Fixturewert beweist nicht, dass der Beobachter lief; das Protokoll beweist nicht den empfangenen Inhalt.
Unser Server zählt Endpunktaufrufe. Mit fallback ist die Reihenfolge observer, fixture; die Seite erhält fixture value und der Serverzähler bleibt null. Eine frische Seite verwendet continue: server value, nur observer im Protokoll und ein Serveraufruf.
Jeden Ausgang sichtbar machen
Ein Beobachter liest und delegiert. Eine Fixture kann mit fulfill antworten, ein Blocker mit abort abbrechen. Jeder Pfad braucht einen ausdrücklichen Ausgang. Gehört ein Request nicht zum bedingten Handler, lässt fallback den nächsten entscheiden, statt ihn versehentlich warten zu lassen.
Die API erlaubt Requeständerungen während fallback. Diese verändern die Eingabe späterer Handler und gehören ins Review. Hier gibt es keine Overrides, Zugangsdaten oder privaten Header. Geprüft wird Kontrollfluss, nicht Headerweitergabe.
Breite und enge Routen können sich überlappen. Lesen Sie alle Registrierungen einschließlich gemeinsamer Helfer. Deren Aufrufzeit beeinflusst die Reihenfolge, unabhängig von der Position im Testtext. Schreiben Sie die beobachtete Reihenfolge in den Fehlerbericht.
Netzwerkgrenzen getrennt prüfen
Eine lokal erfüllte Route prüft Verhalten unter der gelieferten Antwort, keinen echten Anbieter. Auch continue erreicht hier nur einen erfundenen lokalen Server. Halten Sie Integrationstests getrennt und externe Requests in einer erlaubten Umgebung.
Frische Seiten trennen die Registrierungen. Werden Routen innerhalb eines Tests geändert, entfernen Sie den gemeinten Handler ausdrücklich und warten Sie auf relevante Arbeit. Cleanup darf das nächste Setup nicht unbemerkt verändern.
Notieren Sie Endpunkt, Reihenfolge, Ausgänge, Antwort und Serverbeleg. AnyTest beschreibt App-Erkundung und reviewbare Tests. Fragen Sie, welche Abhängigkeit antwortete. Eine bestimmte AnyTest-Interceptionfunktion wird nicht behauptet.
Häufige Fragen
Ruft continue den nächsten Handler auf?
Nein. Es sendet sofort ins Netzwerk.
Garantiert fallback einen Serveraufruf?
Nein. Ein anderer Handler kann antworten oder abbrechen.