Aller au contenu

Tâche 7 du cadre de tests automatisés - Traçabilité, retry et CI/CD sécuritaire

Billet #173 : Renforcement du cadre de tests E2E automatisés par auto-réparation, retry et CI/CD sécuritaire
Type : Automatisation / CI-CD / Sécurité / Fiabilité
Composants concernés : e2e/playwright.config.ts, e2e/src/utils/selfHealingUtil.ts, e2e/src/pages/LoginPage.ts, e2e/package.json, .github/workflows/deploy.yml

1. Contexte et objectif

Cette tâche est la septième et dernière de mon plan d'implémentation du cadre de tests E2E automatisés.

Après avoir posé les fondations du cadre Playwright (Billet #167), structuré la navigation (Billet #168), sécurisé les environnements (Billet #169), industrialisé les données de test (Billet #170), optimisé l'exécution (Billet #171) et ajouté les contrôles réseau avancés (Billet #172), l'objectif était de mettre en place la résilience d'exécution de ce cadre de test automatisé et de l'intégrer au CI.

Le cadrage a toutefois été ajusté pour tenir compte d'une contrainte structurante du projet : l'application tourne sur un environnement de production personnel contenant des données financières réelles. La priorité était donc double :

  • renforcer la robustesse du cadre de test automatisé ;
  • intégrer une exécution CI utile sans exposer d'identifiants de production ni banaliser la production comme environnement de test.

2. Phase 1 — Vérification du retry et de la traçabilité d'exécution

La configuration Playwright a été confirmée autour d'un modèle de résilience adapté au CI :

  • activation de retries uniquement lorsque CI=true ;
  • collecte des traces au premier retry via trace: 'on-first-retry' ;
  • limitation du parallélisme en CI pour réduire les interférences ;
  • conservation d'un rapport HTML pour l'analyse post-exécution.

Ce socle fournit un niveau de traçabilité suffisant pour diagnostiquer un échec intermittent sans alourdir inutilement les runs locaux.

3. Phase 2 — Mise en service de l'auto-réparation sur le flux de connexion

Un utilitaire selfHealingUtil a été consolidé pour essayer plusieurs sélecteurs dans un ordre priorisé et retourner le premier sélecteur exploitable.

L'implémentation finale apporte :

  • un timeout paramétrable ;
  • un choix explicite entre vérification attached et visible ;
  • une variante stricte qui échoue clairement si aucun sélecteur n'est valide.

Cet utilitaire a ensuite été branché dans LoginPage avec des sélecteurs de repli pour :

  • le champ utilisateur ;
  • le champ mot de passe ;
  • le bouton de soumission.

Résultat : le parcours de connexion devient moins fragile face à des ajustements UI mineurs, tout en conservant un échec explicite si l'écran change réellement de contrat.

4. Phase 3 — Intégration d'un gate E2E sécuritaire dans GitHub Actions

Le workflow principal de déploiement a été complété par un job E2E dédié qui :

  • installe le sous-projet Node e2e/ ;
  • installe uniquement Chromium sur le runner CI ;
  • exécute un sous-ensemble de tests Playwright compatibles avec une exécution sans secrets ;
  • publie les artefacts Playwright (playwright-report, test-results) pour diagnostic.

Le déploiement est maintenant conditionné par deux vérifications :

  • les tests backend existants ;
  • le gate E2E sécuritaire.

Le point clé de cette phase est la décision d'exclure du pipeline automatique les scénarios qui nécessitent les credentials de production réelle. Le CI valide donc le cadre de test automatisé, mais ne se connecte pas automatiquement à l'environnement personnel sensible.

5. Incident critique identifié et résolution de gouvernance

Incident — Risque d'exposition indirecte de l'environnement de production
La première version du job E2E CI injectait USER_ID et PASSWORD pour reproduire le flux complet d'authentification. Techniquement, cela était faisable via GitHub Actions. D'un point de vue de gouvernance, ce choix était disproportionné pour un projet personnel contenant des données financières réelles.
Résolution : recentrage du pipeline sur une exécution E2E « safe » sans secrets de production, avec report des scénarios sensibles vers une suite manuelle ou vers un futur environnement non productif.

Cette décision ne diminue pas la maturité du projet. Elle l'améliore en alignant l'automatisation sur une évaluation correcte du risque.

6. Validation et résultats

Les validations finales ont confirmé :

  • absence d'erreurs structurelles dans deploy.yml, LoginPage.ts, selfHealingUtil.ts et e2e/package.json ;
  • détection correcte des tests Playwright pour le projet chromium ;
  • sélection correcte du sous-ensemble E2E sécuritaire exécuté en CI ;
  • intégration effective du self-healing dans le flux de login.

Le cadre livré aujourd'hui est donc :

  • plus résilient en exécution ;
  • plus lisible en diagnostic ;
  • mieux aligné avec les exigences de sécurité du projet.

7. Conclusion et suite

La Tâche 7 est finalisée sur son périmètre livrable aujourd'hui : retry, traçabilité d'exécution, auto-réparation du login et intégration CI/CD sécuritaire.

Deux chantiers complémentaires ont été explicitement sortis du périmètre de cette livraison pour être traités séparément :

  • définition d'un workflow manuel et protégé pour d'éventuels smoke tests en production ;
  • développement d'un environnement E2E non productif avec données synthétiques. La page /demo actuelle sera transformée dans ce but.

Ces suites sont documentées dans des billets GitHub dédiés afin de garder une feuille de route claire sans compromettre la sécurité immédiate du projet.