Aller au contenu

Tâche 2 du cadre de tests automatisés - Navigation intelligente et audit d'architecture

Billet #168 : Navigation intelligente et audit d'architecture du cadre de test E2E automatisé
Type : Automatisation / Qualité / Architecture de test
Composants concernés : e2e/src/pages/HomePage.ts, e2e/src/pages/LoginPage.ts, e2e/src/tests/loginTest.spec.ts, e2e/playwright.config.ts, e2e/package.json, e2e/eslint.config.mts

1. Contexte

Après la mise en place du socle initial Playwright dans la tâche #167, l'étape suivante consistait à quitter la simple logique d'initialisation pour entrer dans une première structuration métier du cadre de test E2E.

L'objectif n'était plus seulement d'avoir un runner fonctionnel, mais de commencer à modéliser la navigation applicative avec une approche plus maintenable, tout en auditant l'organisation réelle des fichiers afin de corriger les incohérences apparues pendant l'initialisation.

2. Objectif

Cette deuxième étape visait à :

  • introduire une première implémentation du Page Object Model sur un scénario de connexion ;
  • mettre en place un mécanisme de chaînage entre pages pour rendre les tests plus lisibles ;
  • créer un premier test E2E orienté parcours utilisateur plutôt qu'un simple smoke test générique ;
  • corriger la structure du dossier e2e/ pour mieux séparer la configuration du code source ;
  • préparer le terrain pour les prochaines briques : fixtures, variables d'environnement et robustesse CI.

3. Implémentation livrée

3.1 — Introduction du Page Object Model avec navigation chaînée

Le fichier e2e/src/pages/LoginPage.ts encapsule désormais les actions principales de la page de connexion :

  • ouverture de la page de login ;
  • saisie du nom d'utilisateur ;
  • saisie du mot de passe ;
  • clic sur le bouton de connexion.

Le point structurant de cette itération est la méthode clickLoginButton(): Promise<HomePage>, qui retourne directement une instance de HomePage après l'action utilisateur. Cette approche introduit un chaînage POM clair et réutilisable.

3.2 — Première abstraction de la page d'accueil

Le fichier e2e/src/pages/HomePage.ts formalise la page cible après authentification et centralise une première vérification métier via expectServiceTitleToBeVisible().

Cette encapsulation pose les bases d'une stratégie plus propre : les assertions ne vivent plus directement dans le scénario de test, mais dans l'objet représentant la page concernée.

3.3 — Création du premier scénario orienté usage réel

Le fichier e2e/src/tests/loginTest.spec.ts orchestre maintenant un scénario de connexion lisible de bout en bout :

  1. création de LoginPage ;
  2. navigation vers l'écran de login ;
  3. saisie des identifiants ;
  4. récupération de HomePage via le chaînage ;
  5. validation de l'écran d'arrivée.

Cette structure marque la transition d'un test technique de démonstration vers un scénario métier extensible, bien plus adapté à la suite du chantier.

3.4 — Audit d'architecture et correction du positionnement des fichiers de configuration

Un incident de structure a été identifié pendant le travail : plusieurs fichiers d'infrastructure (package.json, package-lock.json, playwright.config.ts, eslint.config.mts, .gitignore) étaient restés dans e2e/src/, alors qu'ils relèvent du niveau racine du sous-projet e2e/.

L'audit a conduit à un repositionnement plus cohérent :

  • la configuration du cadre de test reste à la racine e2e/ ;
  • le code source métier reste dans e2e/src/ ;
  • les dossiers pages/ et tests/ conservent leur rôle applicatif.

Cette correction améliore immédiatement la lisibilité du projet, sa maintenabilité et sa compatibilité avec les usages standards d'un sous-projet Node/Playwright.

3.5 — Préparation à l'exécution multi-navigateurs et à la validation visuelle

La configuration e2e/playwright.config.ts conserve l'exécution prévue sur chromium, firefox et webkit, avec génération de rapport HTML.

Une exécution en mode visuel a été lancée via :

npx playwright test loginTest.spec.ts --headed

Cette validation a permis d'exercer la nouvelle chaîne de navigation et de produire les artefacts Playwright attendus, tout en mettant en évidence les derniers ajustements spécifiques à l'application réelle (sélecteurs/identifiants définitifs) avant industrialisation complète.

4. Résultat opérationnel

La tâche #168 ne se limite pas à l'ajout d'un test supplémentaire : elle fait franchir au cadre de test un cap d'architecture.

À l'issue de cette étape, le projet dispose désormais :

  • d'un premier enchaînement de pages métier avec LoginPage -> HomePage ;
  • d'un scénario E2E beaucoup plus proche des usages réels ;
  • d'une séparation plus saine entre configuration et code source ;
  • d'une base propre pour introduire les fixtures, les variables d'environnement et les futures stratégies de sécurisation.

5. Conclusion

Cette livraison correspond à une véritable montée en maturité du chantier Playwright : le cadre de test ne repose plus seulement sur une installation technique, mais sur une architecture de test intentionnelle et extensible.

Le terrain est désormais prêt pour la tâche 3, centré sur la sécurisation des variables d'environnement, la fiabilisation de la gestion des identifiants sensibles et le renforcement du caractère réutilisable des scénarios automatisés.