Tâche 6 du cadre de tests automatisés - Tests API avancés
Billet #172 : Implémentation de la Tâche 6 - Tests API avancés (Surveillance, Interception et Simulation)
Type : Automatisation / API Testing / Fiabilité
Composants concernés : e2e/src/tests/apiNetwork.spec.ts
1. Contexte et objectif
Cette Tâche 6 d'implémentation des tests d'API s'inscrit dans la continuité des travaux précédents : Billet #167, Billet #168, Billet #169, Billet #170 et Billet #171.
L'objectif principal de cette tâche est de contrôler le trafic réseau du navigateur pour rendre les scénarios E2E plus stables, plus prédictibles et moins dépendants de la disponibilité des API back-end.
2. Phase 1 - Surveillance API (surveillance des échanges réseau)
La première phase a consisté à instrumenter la page pour observer les appels sortants et les réponses entrantes.
Le scénario met en place :
page.on('request')pour journaliser la méthode HTTP et l'URL des requêtes ;page.on('response')pour consigner le code de statut HTTP et l'URL de réponse.
Cette surveillance fournit une visibilité immédiate sur les flux réseau, ce qui accélère le diagnostic des erreurs d'intégration UI/API.
3. Phase 2 - API Intercepting (interception et modification à la volée)
La deuxième phase introduit une interception globale du trafic avec page.route('**/*').
Pour chaque requête interceptée, le test :
- récupère les en-têtes existants ;
- injecte un en-tête personnalisé
X-Custom-Header: Integration-Check; - relaie la requête modifiée vers le serveur réel via
route.continue().
Cette approche permet de simuler des conditions d'intégration spécifiques sans modifier le code applicatif côté front-end.
4. Phase 3 - Simulation API (simulation complète de la réponse serveur)
La troisième phase cible une route API dédiée afin de découpler le test de tout service externe.
Le scénario intercepte l'endpoint concerné, bloque l'appel réel, puis retourne une charge JSON fictive au moyen de route.fulfill({ json: fakeResponse }).
Le résultat est déterministe :
- l'UI reçoit des données contrôlées ;
- le test reste exécutable même en cas d'indisponibilité du back-end ;
- les coûts et instabilités liés à des API tierces sont évités.
5. Validation et résultats
La validation a confirmé l'exécution correcte du scénario de simulation en ciblant uniquement le test concerné (Test 3) sur Chromium.
Points validés :
- interception effective de la route API ;
- réponse mockée bien injectée ;
- exécution stable avec isolation réseau (
--no-deps) ; - succès du test en exécution ciblée.
6. Incidents rencontrés et résolutions
Option CLI --slow-mo non reconnue
La commande npx playwright test ne supporte pas ce flag en l'état, provoquant un échec.
Résolution : usage du mode debug PowerShell ($env:PWDEBUG='1') et lancement en --headed pour visualiser l'exécution.
7. Conclusion et feuille de route
La Tâche 6 fournit un socle API robuste pour les scénarios E2E : surveillance des échanges, interception contrôlée et simulation complète des réponses.
Le cadre de test peut désormais tester l'interface de manière plus isolée, rapide et fiable, en limitant les faux positifs liés aux variations d'infrastructure back-end.
Dernière étape (Tâche 7) : consolider la traçabilité d'exécution, les mécanismes de retry et l'intégration CI/CD.