Réponse.

La gestion des données de test est l'un des problèmes les plus anciens de l'automatisation. Dès le début de l'automatisation (scripts de test dans Excel, macros, anciens QTP), les données étaient souvent "gardées en tête" par l'auteur des tests ou directement dans le code. Avec le développement de CI/CD et des exécutions parallèles, de nouvelles stratégies ont été nécessaires : comment éviter les courses lorsque plusieurs tests utilisent simultanément les mêmes données et garantir la répétabilité des résultats ?

Problème : les données de test partagées (shared) conduisent rapidement à des collisions et à des résultats imprévisibles. Les tests deviennent instables, difficiles à déboguer, et les fragments de données "encombrent" les bases, rendant les exécutions en plusieurs fils sujettes à des erreurs (data race).

Solution — mise en œuvre de stratégies "données de test par test" (Test Data Per Test) :

Utilisation de données de test uniques ou paramétrées pour chaque test
Génération/nettoyage des données avant et après le test (setup/teardown, fixtures)
Séparation des environnements de test à l'aide de namespaces, tenants, users
Utilisation de bases in-memory avec réinitialisation par test

Caractéristiques clés :

Génération de données uniques (UUID, timestamp), suppression automatique après le test
Utilisation de modèles et de fabriques de données de test (Test Data Factories)
Travail avec des environnements sandbox isolés

Questions pièges.

Est-il normal d'utiliser des données de production comme données de test ?

Non ! C'est risqué pour la sécurité, la confidentialité, et cela entraîne des résultats de tests imprévisibles en raison de la variabilité des données.

Est-il suffisant d'utiliser setUp et tearDown pour nettoyer les données ?

Pas toujours. Ils aident à minimiser les risques, mais les exécutions parallèles peuvent heurter les tests si les données restent globales ou ne sont pas uniques.

Peut-on utiliser les mêmes données de test dans des scénarios de smoke et de regression ?

Mieux vaut non. Les tests smoke doivent être le plus indépendants possible, tandis que les tests de régression nécessitent une préparation complexe des données, sinon des faux positifs peuvent se produire.

Erreurs typiques et anti-patterns

Utilisation de données partagées, "magiques", qui conviennent accidentellement à de nombreux tests
Artefacts de données non nettoyés après test
Réutilisation des mêmes enregistrements dans tous les tests

Exemple de la vie réelle

Cas négatif

Dans l'entreprise, il y avait un login commun et plusieurs utilisateurs et commandes "partagés", utilisés dans tous les tests automatisés. L'exécution parallèle conduisait à ce que les tests effacent les commandes de l'autre ou modifient l'état d'une commande dans plusieurs fils.

Avantages :

Rapide et simple à mettre en œuvre avec un petit nombre de tests
Pas besoin d'infrastructure supplémentaire

Inconvénients :

Échecs ambigus, difficultés de débogage
Impossible de lancer des tests en toute sécurité en parallèle ou dans différents environnements

Cas positif

Des fabriques de données de test ont été mises en place : avant l'exécution du test, pour chaque scénario, une commande et un utilisateur uniques étaient créés et supprimés à la fin du test, et l'environnement sandbox était réinitialisé.