Tâche 1 du cadre de tests automatisés - Mise en place des fondations techniques

Billet #167 : Mise en place des fondations techniques du cadre de test E2E automatisé
Type : Automatisation / Qualité / Infrastructure de test
Composants concernés : e2e/src/package.json, e2e/src/playwright.config.ts, e2e/src/eslint.config.mts, e2e/src/tests/example.spec.ts, e2e/src/.gitignore

1. Contexte

Dans le cadre du développement de cette application SaaS Augmented Financial Analyst, plusieurs processus critiques devaient être sécurisés et automatisés de façon fiable, notamment l’authentification et la navigation dans l’application.

Le choix a donc été de construire un véritable cadre de test bout en bout plutôt que d'accumuler des scripts de test isolés. Cette approche répond à un besoin d'ingénierie de la qualité plus mature : disposer d'une base capable de soutenir la croissance de l'application, l'exécution parallèle des tests, la gestion future de plusieurs environnements, l'intégration continue (CI/CD) et, à terme, des mécanismes de robustesse comme les retries et l'auto-réparation.

La tâche 1 correspondait à cette phase de fondation. Avant d'automatiser les parcours métier, il fallait poser un cadre de travail stable, propre et maintenable pour que le cadre de test puisse évoluer sans devenir fragile ni difficile à exploiter.

2. Objectif

L'objectif de cette première tâche était de poser les briques minimales indispensables pour qu'un cadre de test E2E puisse vivre dans la durée, et non simplement fonctionner de façon ponctuelle.

Concrètement, cela impliquait :

initialiser le projet avec Node.js et NPM, afin de disposer de l’environnement d’exécution nécessaire pour faire tourner le code TypeScript localement puis plus tard en CI/CD, tout en garantissant une réinstallation fiable et reproductible des dépendances ;
installer les moteurs de navigateurs Playwright, afin d’exécuter les tests rapidement sur les moteurs de rendu (Chromium, Firefox, WebKit) sans dépendre d’interfaces graphiques lourdes ;
structurer le cadre de test en dossiers dédiés (config, pages, utils, data, tests) pour préparer une architecture claire, compatible avec le Page Object Model et plus facile à maintenir lorsque l'interface évoluera ;
mettre en place un premier filet de qualité avec ESLint, pour détecter tôt les erreurs de syntaxe et imposer des standards de code homogènes ;
ajouter un test fumée, afin de valider que le runner, les navigateurs et la mécanique d’exécution sont bien opérationnels dès la première itération.

3. Implémentation livrée

3.1 — Initialisation du socle Node + Playwright

Le fichier e2e/src/package.json introduit les dépendances de base nécessaires à la construction du cadre de test :

@playwright/test
typescript
eslint
typescript-eslint
@eslint/js
globals
@types/node

Cette base installe immédiatement un environnement orienté tests E2E, qualité statique et maintenabilité.

3.2 — Structuration initiale du cadre de test

Le répertoire e2e/src/ a été préparé avec une arborescence modulaire :

config/
data/
pages/
utils/
tests/

Même si ces dossiers sont encore au stade de fondation, la séparation des responsabilités est déjà en place. Cette décision facilite la suite du chantier, notamment pour le Page Object Model, les fixtures et les jeux de données.

3.3 — Configuration d’exécution multi-navigateurs

Le fichier e2e/src/playwright.config.ts pose plusieurs choix structurants dès la première tâche :

définition du répertoire de tests
activation de forbidOnly en contexte CI
configuration de retries sur CI
limitation des workers en environnement d’intégration continue
génération d’un rapport HTML
capture de trace au premier retry
préparation des exécutions sur :
chromium
firefox
webkit

Cette configuration montre que le socle a été pensé dès le départ pour aller vers un usage plus robuste et plus professionnel qu’un simple script local.

3.4 — Intégration du contrôle qualité avec ESLint

Le fichier e2e/src/eslint.config.mts introduit une configuration de linting pour le code JavaScript et TypeScript.

Ce garde-fou est important car il installe une discipline de qualité dès la naissance du cadre de test, au lieu de repousser cette exigence à une phase ultérieure.

3.5 — Ajout d’un premier test fumée

Le fichier e2e/src/tests/example.spec.ts fournit deux tests de démarrage :

vérification du titre de la page playwright.dev
navigation vers la page “Get started”

Ce test n'a pas vocation à couvrir un besoin métier du produit ; il sert à valider l'initialisation du cadre de test, le comportement du runner et la préparation du futur terrain d'automatisation.

3.6 — Hygiène Git et maîtrise des artefacts

Le fichier e2e/src/.gitignore exclut les éléments générés qui ne doivent pas polluer le dépôt :

node_modules/
test-results/
playwright-report/
blob-report/
caches Playwright
données d’authentification locales

Cette décision répond directement à l’exigence de propreté du dépôt et de sécurisation minimale du périmètre E2E.

4. Résultat opérationnel

La tâche #167 a permis de faire passer le projet d'une simple intention de cadre de test à une fondation technique versionée et structurée.

À l’issue de cette première livraison, le dépôt dispose désormais :

d’un espace E2E dédié
d’une base Playwright installée
d’une configuration d’exécution initiale
d’un garde-fou qualité avec ESLint
d’un premier test fumée
d’une hygiène Git adaptée aux artefacts de test

Cette base ne représente pas encore le cadre de test métier complet, mais elle constitue le point d'ancrage concret sur lequel pourront s'ajouter les prochaines briques : Page Object Model, fixtures personnalisées, gestion des environnements, DDT, robustesse et CI/CD.