Test flaky (test instable)

Un test flaky (instable) donne un résultat différent sur le même commit. Exécutez-le dix fois sur du code inchangé et vous obtenez des succès et des échecs. Sa caractéristique déterminante est que rien n’a changé dans le produit : la variation vient du test, de ses données ou de son environnement.

Pourquoi c’est important

Une suite qui contient quelques tests flaky apprend à l’équipe à relancer les échecs jusqu’à ce qu’ils passent au vert. Une fois cette habitude installée, les vraies régressions finissent elles aussi par disparaître à force de relances. L’instabilité ralentit aussi les pipelines, car les retries multiplient le temps d’exécution, et elle érode la confiance dans l’automatisation plus vite qu’une couverture insuffisante.

Causes fréquentes

• Le timing. Le test agit avant que la page ou l’API soit prête : un sleep fixe, une vérification qui lit une valeur une seule fois au lieu de réessayer, ou une animation encore en cours.
• Un état partagé. Deux tests écrivent le même utilisateur, le même panier ou la même ligne en base. Ils passent seuls et échouent en parallèle ou dans un autre ordre.
• La dépendance à l’ordre des tests. Un test s’appuie sur des données créées par un test précédent.
• L’environnement. Environnements de test lents ou partagés, services tiers, limites de débit, fuseaux horaires et changements d’heure.
• Des données non déterministes. Des entrées aléatoires sans graine (seed) journalisée, ou des assertions sur « maintenant ».

Comment le traiter

1. Le reproduire. Exécutez le test seul en boucle (Playwright : npx playwright test my.spec.ts --repeat-each=20) et capturez une trace ou une vidéo d’une exécution en échec.
2. Trouver la cause au lieu d’ajouter un retry. Remplacez les pauses par des attentes basées sur des conditions, comme les assertions web-first de Playwright ou WebDriverWait dans Selenium. Donnez à chaque test ses propres données.
3. Le mettre en quarantaine si vous ne pouvez pas le corriger aujourd’hui. Sortez-le du contrôle bloquant et placez-le dans un job non bloquant suivi, avec un responsable, pour que le signal principal reste fiable.
4. Suivre le taux d’instabilité dans le temps. Les retries qui réussissent masquent le problème, sauf si le rapport les affiche.

Les retries (retries: 2 dans playwright.config.ts) sont un filet de sécurité raisonnable en CI, mais un test qui ne passe qu’au retry reste un test flaky. Playwright les signale comme « flaky » pour que vous puissiez les voir.