Tâche 5 du cadre de tests automatisés - Optimisation des performances et de la robustesse
Billet #171 : Optimisation des performances et de la robustesse du cadre de test E2E automatisé (Storage State et secrets externes Windows)
Type : Automatisation / Performance / Sécurité / Fiabilité
Composants concernés : e2e/playwright.config.ts, e2e/src/tests/auth.setup.ts, e2e/src/tests/skipLogin.spec.ts, e2e/src/tests/loginTest.spec.ts, e2e/src/utils/requiredEnv.ts, e2e/scripts/save-windows-secrets.ps1, e2e/scripts/run-with-windows-secrets.ps1, e2e/package.json, .gitignore
1. Contexte et objectif
Cette intervention correspond à la Tâche 5 du plan d'implémentation du cadre d'automatisation E2E.
Après avoir structuré le socle (Billet #167), stabilisé la navigation (Billet #168), sécurisé les environnements (Billet #169) et industrialisé les données de test (Billet #170), l'objectif de la Tâche 5 est de réduire le coût d'exécution et augmenter la robustesse des runs E2E, via la réutilisation de session et un modèle de secrets hors projet.
2. Phase 1 - Optimisation par Storage State
Le flux a été consolidé en deux étapes :
- un scénario de préparation qui authentifie l'utilisateur et génère un état de session ;
- des scénarios fonctionnels qui réutilisent cet état pour démarrer directement en zone authentifiée.
La configuration Playwright a été alignée autour de :
- un projet
setuppour créer l'état de session ; - des projets navigateurs dépendants (
chromium,firefox,webkit) qui consomment automatiquement cet état.
Résultat attendu : exécutions plus rapides et plus stables, en local comme en pipeline.
3. Phase 2 - Sécurité : secrets totalement hors projet
Le modèle d'authentification a été renforcé pour éviter la présence de secrets dans le code versionné :
- suppression de la dépendance aux fichiers de secrets du projet ;
- lecture obligatoire de
USER_IDetPASSWORDvia variables d'environnement externes ; - garde-fou explicite avec échec immédiat si une variable manque ;
- exclusion stricte de l'état de session local pour éviter toute fuite de jetons.
Cette approche homogénéise les pratiques de sécurité entre local et CI, sans exposer d'identifiants applicatifs.
4. Phase 3 - Ergonomie locale Windows sécurisée
Pour éviter la saisie répétée des identifiants à chaque session :
- ajout d'un script de sauvegarde one-shot des secrets utilisateur ;
- chiffrement local via mécanisme natif Windows (DPAPI), lié au compte utilisateur ;
- ajout d'un script de lancement qui recharge les secrets protégés puis exécute Playwright.
Des commandes npm dédiées ont été ajoutées pour standardiser le flux quotidien de test.
5. Incidents rencontrés et résolutions
Incident 1 - Sélecteur de connexion invalide
Un sélecteur obsolète provoquait des timeouts.
Résolution : alignement sur le sélecteur réel du bouton de soumission.
Incident 2 - Validation post-login fragile
Une assertion basée sur un élément non stable déclenchait des erreurs de type element(s) not found.
Résolution : adoption d'assertions d'état authentifié plus robustes.
Incident 3 - Variables externes manquantes
Le setup échouait si USER_ID / PASSWORD n'étaient pas injectés.
Résolution : garde-fou explicite et flux d'exécution documenté.
Incident 4 - Exécution wrapper Windows via npx
Des erreurs de résolution de modules npm/npx sont apparues selon le contexte shell.
Résolution : exécution directe du binaire Playwright local pour stabiliser le lancement.
6. Validation et résultats
Les validations finales ont confirmé :
- génération correcte de l'état de session ;
- exécution réussie des scénarios skip-login en Chromium ;
- suppression de la ressaisie manuelle des identifiants a chaque session ;
- cohérence du modèle de sécurité hors projet.
7. Conclusion et feuille de route
La Tâche 5 améliore concrètement la performance d'exécution et la robustesse opérationnelle du cadre de test E2E automatisé.
Prochaine étape (Tâche 6) : ajouter les tests avancés API et visuels.
Dernière étape (Tâche 7) : mettre en place la traçabilité, le retry et le CI/CD.