Réponse.

L'automatisation des tests a historiquement commencé avec l'idée d'augmenter la vitesse et de réduire le facteur humain dans les vérifications, mais il est rapidement devenu évident que les tests automatisés se comportent souvent différemment à chaque exécution. La répétabilité (repeatability) et la déterminisme (determinism) sont parmi les exigences fondamentales de la qualité des tests automatisés, qui doivent donner le même résultat dans les mêmes conditions.

Les problèmes commencent à cause des dépendances implicites : données de test instables, environnements non synchronisés, processus parallèles ou services externes. Cela conduit à des tests flaky — leurs résultats sont imprévisibles.

Les solutions sont basées sur un contrôle strict de l'environnement d'exécution, l'isolation des tests, des objets mock/stub, des données statiques et des scénarios reproductibles (par exemple, nettoyage et préparation de la BDD avant chaque test).

Caractéristiques clés :

Contrôle des données de test et initialisation prévisible du banc d'essai.
Isolation des tests les uns des autres et abandon des dépendances entre tests.
Utilisation d'objets Mock/Stub pour travailler avec des services instables ou externes.

Questions piégeuses.

Que faire si un test flaky se produit uniquement dans CI, alors que tout est stable localement ?

Cela est presque toujours lié aux différences entre les environnements : versions des dépendances, rapidité de l'infrastructure, parallélisme, paramètres du système d'exploitation ou ordre d'exécution des tests. La solution consiste à rapprocher autant que possible l'environnement CI de la machine de développement (Docker, mêmes valeurs de seed, configuration de setUp/tearDown dans les tests).

Peut-on considérer les tests paramétrés comme entièrement déterministes si les données proviennent d'une base de données ?

Non. Même si les données de base correspondent, la BDD peut changer entre les tests ou entre les versions. Pour une véritable déterminisme, les données doivent être préparées et nettoyées explicitement dans chaque test.

Si l'on utilise sleep pour attendre le chargement des éléments, cela résoudra-t-il le problème d'instabilité des tests UI ?

Non. Sleep ne fait que masquer le problème et ralentir l'exécution des tests. Il est correct d'utiliser des attentes explicites (Explicit Waits), qui attendent des conditions spécifiques, et non un temps fixe.

Erreurs typiques et anti-modèles

Utilisation de "nombres magiques" et de délais au lieu d'une synchronisation correcte.
Dépendance entre tests ou modification de l'état de l'environnement, non annulée entre les tests.
Mélange de données de test entre scénarios.

Exemple de vie

Cas négatif

Dans le projet, des tests UI étaient exécutés sur un banc d'essai qui n'était pas nettoyé après les tests manuels. Une fois tous les quelques nuits, les tests échouaient avec des erreurs "aléatoires" qui n'étaient pas présentes localement. L'équipe a ajouté sleep dans les tests et a ignoré les problèmes flaky.

Avantages :

Pas besoin de passer beaucoup de temps à résoudre le problème à la racine.
Les tests permettaient parfois de trouver des bugs.

Inconvénients :

Temps perdu en réexécutions.
Les faux résultats négatifs décourageaient les ingénieurs.
Les rapports étaient couverts de bruit, la véritable régression pouvait être manquée.

Cas positif

Après l'arrivée d'un ingénieur DevOps mature, l'équipe a mis en œuvre des scripts pour réinitialiser et initialiser les données de test, a ajouté des services mock pour les intégrations instables et a commencé à exécuter des tests dans des conteneurs. Les tests flaky ont presque disparu.