Simulez la dépendance. Nommez la limite.

Un devis de livraison échoue lors d'un contrôle de lancement. L'interface utilisateur de paiement est-elle cassée, le fournisseur de devis est-il indisponible ou l'environnement de test a-t-il perdu ses informations d'identification ? Un résultat rouge représente désormais plusieurs systèmes. Une réponse contrôlée peut vous aider à examiner l'interface utilisateur, mais elle modifie la signification du résultat.

Ce guide utilise un petit écran de devis de livraison pour montrer comment simuler une dépendance et étiqueter honnêtement les preuves. Il est basé sur le [guide moqueur de Playwright] (dépendance https://playwright.dev/docs/simulated) et la documentation réseau. L'écran présenté ici est une démo illustrative locale avec des options d'expédition inventées, et non un flux de travail client ou un service en direct.

Décidez à quelle question répond le test

La question de l'interface utilisateur est de savoir si la page affiche un prix renvoyé, gère une liste vide et explique un devis indisponible. La question d'intégration est de savoir si le service réel accepte la demande et renvoie la forme de réponse convenue. Vous pouvez les tester séparément et conserver une vérification de service réel plus petite à côté d'une suite d'interface utilisateur déterministe.

N'appelez pas le chemin simulé une preuve complète de bout en bout du service. Sa valeur est plus étroite : votre frontend reçoit des données connues et se comporte correctement. C'est une preuve utile lorsqu'elle est nommée correctement. Une dépendance simulée verte ne peut pas vous dire si un fournisseur a modifié ses informations d'identification, rejeté votre charge utile ou arrêté de desservir votre région.

Installez la route avant que la requête n'arrive

Dans cette application illustrative, le chargement de la page de devis demande /api/delivery-quote. L'exemple intercepte ce chemin exact et renvoie un objet JSON contrôlé. Enregistrez le gestionnaire avant de naviguer afin que la première requête ne puisse pas échapper à la configuration prévue.

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

Utilisez une baseURL de préparation configurée pour cette navigation relative. La forme de réponse est notre contrat de démonstration, et non une API de livraison universelle. Un test réel doit utiliser votre schéma documenté et vos règles de devise. Faites correspondre uniquement le point de terminaison que vous souhaitez contrôler ; intercepter tout le trafic peut masquer des pannes sans rapport.

L'API Route de Playwright fait la distinction entre l'exécution d'une requête et la récupération d'une réponse réelle et sa modification. L'exemple ci-dessus n'appelle pas le service de devis en amont. Un exemple route.fetch() aurait une limite différente car elle dépend toujours de la réponse en amont.

Testez les états d'échec sans attendre une panne du fournisseur

Renvoyez une réponse 503 lors d'un deuxième test, puis vérifiez que la page explique que le devis n'est pas disponible et propose la prochaine action prévue. Un troisième test peut renvoyer un résultat vide réussi s'il s'agit d'un état significatif dans votre contrat. Gardez chaque configuration petite et explicite.

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

Ces extraits appartiennent à des cas de test distincts. L'application doit implémenter ce comportement d'alerte ; ce n'est pas un matcher qui le crée. Vérifiez qu'un utilisateur dispose d'une prochaine étape sûre, et pas seulement qu'un texte rouge apparaisse. Ne simulez jamais un paiement effectué pour prouver qu'un paiement réel fonctionne.

Surveillez les angles morts

Un service worker peut intercepter les requêtes avant que la page ou le routage contextuel de Playwright ne les voie. La documentation réseau recommande de bloquer les techniciens de service lorsque le routage natif ne répond pas aux requêtes attendues. Choisissez délibérément ce paramètre dans votre configuration de test contrôlé ; le modifier peut supprimer un comportement que vous auriez autrement besoin de tester.

Le routage au niveau du contexte du navigateur peut couvrir les pages et les fenêtres contextuelles dans le contexte, alors qu'une règle au niveau de la page a une portée plus étroite. Décidez du comportement dont vous avez besoin plutôt que de déplacer chaque règle vers la portée la plus large. Conservez les gestionnaires de routes et les données du test dans son cycle de vie.

Les archives HTTP enregistrées peuvent également relire le trafic, mais les enregistrements peuvent contenir des en-têtes, des cookies et des données de réponse sensibles. Examinez et désinfectez un enregistrement avant de le stocker. Pour ce simple cas de citation, une réponse rédigée à la main est plus facile à inspecter qu'une grande archive capturée.

Donnez à la preuve un nom qui survit au tableau de bord

Utilisez un titre de test tel que l'interface utilisateur du devis de livraison, la réponse simulée du fournisseur. Dans les notes de révision, indiquez le point de terminaison contrôlé, la version du contrat et la vérification en service réel distincte. Un coéquipier ne devrait pas avoir besoin d'inspecter le code d'itinéraire pour découvrir que le fournisseur était absent.

AnyTest décrit l'exploration basée sur les URL et teste l'examen humain. Appliquez la même question de preuve à tout flux proposé : quelles dépendances étaient réelles, lesquelles étaient contrôlées et qu'établit une passe ? Ce guide ne revendique pas d'interface moqueuse spécifique dans AnyTest.

Pour une petite équipe QA, le gain est un chemin de diagnostic plus clair et une couverture délibérée des états de défaillance. Pour une suite de tests appartenant à un développeur, c'est la même chose : gardez des vérifications d'interface utilisateur répétables, gardez la limite d'intégration visible et ne laissez pas une dépendance simulée pratique devenir une promesse plus grande que ce que le test peut prendre en charge.