QA The Other WayAssurance qualité à l'ère des tests écrits par l'IA. QA The Other Way.
QA pratique

Une erreur HTTP reste une réponse HTTP.

Séparez statut non réussi et échec de transport dans le diagnostic d'une requête.

5 min de lectureQA The Other Way
Schéma original séparant réponse HTTP en erreur et transport interrompu.
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.

Séparez statut non réussi et échec de transport dans le diagnostic d'une requête.
Exemple local avec données inventées, sans interface client ou fournisseur.

Un panneau ne charge pas et le test attend requestfailed. Rien n'arrive : le serveur a envoyé une réponse HTTP en erreur. L'absence de cet événement ne prouve pas le succès produit. Le test interroge la mauvaise frontière.

Ce guide utilise la documentation réseau Playwright et Page avec deux requêtes locales inventées : réponse 503 contrôlée et requête interrompue par une route. Aucun endpoint client ou incident externe. Nous séparons statut et transport.

Lisez explicitement le statut

L'API décrit request, response et requestfinished pour une requête terminée. Les erreurs HTTP restent des réponses et ne sont pas requestfailed. Le transport peut finir tandis que le comportement produit échoue.

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');

Le bouton local et le serveur contrôlé sont requis. L'interface annonce volontairement l'erreur. Attendre 503 convient à ce cas négatif, pas à un vrai parcours réussi.

Installez l'attente avant l'action. Choisissez endpoint et identité selon le contrat. Un écouteur large peut prendre une autre réponse pour preuve.

Utilisez requestfailed pour sa question

Il indique l'absence d'une réponse normalement terminée, par exemple un problème de transport. Le deuxième exemple utilise route.abort(). On vérifie l'URL choisie et une description, sans imposer un texte identique entre navigateurs.

Une interruption n'est pas un 503 serveur. Gardez noms et attentes séparés. Si les deux doivent proposer une relance, vérifiez chaque configuration sans mélanger les causes.

Un événement seul n'identifie pas la cause de production. Il guide l'enquête sans localiser serveur, saut réseau ou politique. Combinez les preuves pertinentes dans l'environnement autorisé.

Ne confondez pas transport et résultat métier

Une réponse peut avoir un statut valide et un mauvais dossier ou corps d'erreur. Le statut ne suffit pas. Vérifiez contenu et état attendus sans élargir cette démonstration.

Le serveur compte un 503 terminé et le test confirme l'absence de requestfailed. L'interruption produit cet événement. Cela valide la sémantique, ne mesure pas la fiabilité et ne reproduit pas une panne externe.

Ne répétez pas les clics parce qu'un événement manque. Le serveur peut avoir reçu l'opération; les clics la dupliqueraient. Identifiez la frontière et la relance autorisée.

Gardez un vocabulaire concret

Notez endpoint, statut ou événement attendu, résultat interface et inconnues. C'est plus utile que Réseau échoué. Protégez URLs et corps privés avant partage.

AnyTest décrit tests révisables après exploration. Demandez si le bon événement et la récupération attendue sont vérifiés. Aucune implémentation réseau AnyTest n'est affirmée. Séparez réponse non réussie et absence de réponse terminée.

Questions courantes

HTTP 503 déclenche-t-il automatiquement requestfailed ?

Non. C'est une réponse dont il faut lire le statut explicitement.

requestfinished prouve-t-il le succès métier ?

Non. Transport, statut, contenu et résultat produit sont distincts.

Sources