QA The Other WayAssurance qualité à l'ère de l'automatisation par IA. QA The Other Way.
QA pratique

Route fallback conserve la chaîne de gestionnaires.

Vérifiez l'ordre d'enregistrement avant de poursuivre une requête interceptée.

5 min de lectureQA The Other Way
Une chaîne de gestionnaires à côté d'un trajet direct vers un serveur inventé.
Illustration éditoriale originale.
Vidéo d'illustration pour cet article. Texte en anglais à l'écran ; sélectionnez les sous-titres pour cette langue.

Édition traduite. Les identifiants techniques restent sous leur forme originale.

Vérifiez l'ordre d'enregistrement avant de poursuivre une requête interceptée.
Exemple local avec données inventées, pas une interface client ou fournisseur.

Un test local enregistre une fixture de réponse puis un observateur du même endpoint. L'observateur appelle continue(). La fixture ne tourne pas, la requête atteint le serveur. La méthode de transmission détermine le comportement combiné.

L'API Route décrit l'ordre inverse de l'enregistrement. Le dernier gestionnaire correspondant s'exécute en premier. fallback() passe au suivant ; continue() envoie immédiatement au réseau sans invoquer les autres.

Définir la chaîne

Pour /demo-value, enregistrez la fixture avant l'observateur. L'observateur tourne d'abord, puis la fixture fournit sa chaîne contrôlée. Le gestionnaire du serveur local ne doit recevoir aucun appel.

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();
});

L'exemple suppose une page locale et une requête ultérieure. Vérifiez texte reçu et ordre enregistré. La valeur fixture ne prouve pas l'exécution de l'observateur ; le journal ne prouve pas le contenu reçu.

Notre serveur compte les appels. Avec fallback : observer puis fixture, fixture value et zéro appel. Une page neuve utilise continue : server value, seulement observer et un appel serveur.

Montrer chaque sortie

Un observateur lit puis délègue. Une fixture peut répondre avec fulfill ; un bloqueur interrompt avec abort. Chaque branche doit sortir explicitement pour ne pas laisser une requête attendre. Si un gestionnaire conditionnel ne prend pas la requête, fallback laisse décider le suivant.

L'API permet des modifications pendant fallback. Elles changent les entrées suivantes et doivent être revues. Ici, aucune modification, donnée d'accès ou en-tête privé. Nous isolons le contrôle, pas la propagation d'en-têtes.

Des routes larges et étroites peuvent se chevaucher. Lisez tous les enregistrements, y compris les helpers partagés. Leur heure d'appel compte davantage que leur position dans le fichier. Rapportez l'ordre observé plutôt que de déduire l'exécution de la mise en page du code.

Vérifier séparément le réseau

Une route satisfaite localement vérifie la réponse fournie, pas le fournisseur réel. Même continue atteint seulement un serveur local inventé. Gardez les tests d'intégration séparés et le trafic externe dans un environnement autorisé.

Les pages neuves séparent les enregistrements. Si vous changez les routes dans un test, retirez explicitement le bon gestionnaire et attendez le travail concerné. Le nettoyage ne doit pas modifier silencieusement le cas suivant.

Notez endpoint, ordre, sorties, réponse et preuve serveur. AnyTest décrit exploration et tests à revoir. Demandez quelle dépendance a répondu. Aucune fonction d'interception AnyTest particulière n'est revendiquée.

Questions courantes

continue appelle-t-il le gestionnaire suivant ?

Non. Il envoie immédiatement au réseau.

fallback garantit-il un appel serveur ?

Non. Un autre gestionnaire peut répondre ou interrompre.

Sources