Tâche 4 du cadre de tests automatisés - Intelligence des données
Billet #170 : Implémentation de la Tâche 4 - Intelligence des données (Faker et DDT)
Type : Automatisation / Qualité / Données de test
Composants concernés : e2e/src/utils/dataGenerator.ts, e2e/src/data/contacts.json, e2e/src/tests/contactDataDriven.spec.ts
1. Contexte et objectif
Cette intervention poursuit la construction du cadre de test E2E automatisé avec un objectif clair : rendre les tests E2E plus robustes et évolutifs sans recourir à des données de production.
Elle s'inscrit dans la continuité directe des tâches de Mise en place des fondations techniques, navigation intelligente et audit d'architecture, et sécurisation des environnements et protection des identifiants.
La Tâche 4 introduit une logique d'intelligence des données de test autour de Faker et du Data-Driven Testing (DDT), afin de multiplier les scénarios couverts tout en limitant le coût de maintenance des scripts.
2. Phase 1 - Génération de données synthétiques avec Faker
Pour respecter les exigences de sécurité et de confidentialité, la librairie @faker-js/faker a été intégrée au sous-projet E2E.
Un utilitaire dédié a été mis en place dans dataGenerator.ts pour :
- définir un modèle de données de contact simple (
firstName,lastName) ; - générer un volume paramétrable de contacts aléatoires ;
- exporter ces données dans un fichier JSON statique (
contacts.json) versionnable.
Ce mécanisme permet de simuler des cas réalistes et variés sans exposer de données sensibles, tout en gardant un jeu de données stable pour les exécutions locales et CI.
3. Phase 2 - Passage à une stratégie Data-Driven Testing (DDT)
Le scénario de test a été restructuré pour charger un fichier de données externe, puis itérer dynamiquement sur chaque contact.
Ce choix évite la duplication de code pour chaque variante et rend l'ajout de nouveaux cas quasi instantané : il suffit d'étendre le JSON sans modifier la logique de test.
Un point clé a été préservé : des titres de tests dynamiques et explicites, par exemple :
Test de création pour le contact : Irma Bauch
En cas d'échec, le rapport HTML identifie directement la donnée en cause, ce qui accélère fortement le diagnostic.
4. Incident d'architecture rencontré et résolution
Incident observé
Lors d'une première tentative de génération directe dans le fichier de test, l'exécution a provoqué l'erreur suivante :
Test not found in the worker process. Make sure test title does not change.
Diagnostic
Cette erreur a révélé le fonctionnement en deux temps de Playwright :
- phase de découverte des tests ;
- phase d'exécution par workers parallèles.
Quand les données étaient régénérées pendant la lecture du fichier, les titres de tests variaient entre ces deux phases, cassant la correspondance attendue par les workers.
Résolution appliquée
Le correctif a consisté à séparer clairement les responsabilités :
- génération des données dans un script utilitaire dédié ;
- consommation d'un JSON statique dans le fichier de test.
Cette séparation garantit des titres stables et compatibles avec l'architecture parallèle de Playwright.
5. Validation et résultats
La validation a confirmé une exécution fluide de 9 tests :
- 3 jeux de données (contacts) ;
- 3 moteurs navigateur (
chromium,webkit,firefox) ; - exécution parallélisée sans conflit de titre.
La gestion d'environnement basée sur les fichiers .env a continué de fonctionner en arrière-plan pendant toute la boucle de test.
6. Conclusion
Le cadre de test dispose maintenant d'un socle DDT opérationnel, capable d'absorber un grand nombre de variations de données via des fichiers externes, sans changer la logique métier des scénarios.
Cette tâche réduit drastiquement le temps de maintenance, augmente la lisibilité des rapports d'échec et prépare la suite des travaux E2E à plus grande échelle.