Votre suite automatisée échoue au hasard environ cinq pour cent du temps. Comment traitez-vous les tests instables ?

Mettez-les d'abord en quarantaine pour que la suite redevienne digne de confiance, puis corrigez les causes profondes au lieu de les masquer avec des relances. Les causes habituelles sont la synchronisation et le temps (pauses fixes, conditions de course), des données de test partagées ou résiduelles, une dépendance à l'ordre d'exécution, et des environnements instables. Corrigez en attendant des conditions plutôt que des durées, en isolant les données par test, et en rendant chaque test indépendant de l'ordre d'exécution.

La première chose que je fais est d'arrêter l'hémorragie, parce qu'une suite qui échoue au hasard finit ignorée, et une fois que les gens l'ignorent vous n'avez plus aucun filet. Les tests instables partent donc en quarantaine dans une exécution séparée qui ne bloque pas le pipeline, avec un ticket et un responsable, ni supprimés ni relancés en silence pour l'éternité. Ensuite je les diagnostique vraiment. Le plus gros paquet de loin, c'est la synchronisation : quelqu'un a mis une pause fixe, ou a fait une assertion juste après un clic alors que la requête est encore en vol. Le remède est d'attendre une condition, par exemple que l'élément soit interactif ou que l'appel réseau se résolve, jamais une durée. Le deuxième paquet, ce sont les données : deux tests qui utilisent le même compte, ou un test qui suppose un état vide que l'exécution précédente a pollué. Je corrige cela en créant les données par test avec un identifiant unique. Le troisième, c'est la dépendance à l'ordre, que je fais sortir en exécutant délibérément la suite dans un ordre aléatoire. Et je suis le taux d'instabilité sur un tableau de bord, parce que ce qui n'est pas mesuré revient en douce. Tout ce qui dépasse environ un pour cent, je le traite comme un vrai problème.