La construction devient rouge, quelqu’un clique sur “réexécuter”, elle réussit et tout le monde passe à autre chose. Cela semble inoffensif, mais les tests irréguliers détruisent lentement ce qu’une suite de tests possède de plus précieux : la confiance des gens en elle. Lorsque les échecs sont généralement du bruit, de vrais bugs sont également signalés.

Ce guide explique pourquoi les tests deviennent instables et comment résoudre correctement chaque cause. Nous avons exécuté les démos de synchronisation et d’état partagé dans Python 3.13, et les chiffres affichés proviennent de ces exécutions. Il s’agit de petites démonstrations conçues pour rendre la desquamation facile à voir, de sorte que vos propres taux d’échec seront différents.

Qu’est-ce qu’un test feuilleté ?

Un test irrégulier donne des résultats différents sur le même code. Il réussit une exécution et échoue la suivante, même si rien dans le produit n’a changé. Le test peut être erroné ou le code peut contenir un véritable bug intermittent. Cette deuxième possibilité est exactement la raison pour laquelle vous ne devriez pas simplement les rejeter.

Pourquoi les tests irréguliers sont si coûteux

• Confiance perdue. Une fois que les gens supposent que le rouge signifie « probablement floconneux », ils arrêtent d’enquêter sur les échecs réels.
• Temps perdu. Les développeurs passent des heures à réexécuter les pipelines et à examiner les échecs qui n’ont rien à voir avec leur modification.
• Livraison plus lente. Les fusions et les versions attendent les réexécutions, ce qui compromet l’intérêt de CI/CD.
• Bogues cachés. Les conditions de concurrence dans le produit peuvent ressembler à du bruit de test, et ce sont celles-là qui nuisent à la production.

Les causes courantes en un coup d’œil

Cause 1 : synchronisation et mises en veille fixes

C’est la cause la plus courante. Un test suppose que le travail en arrière-plan sera terminé après un délai fixe. Pour voir l’effet, nous avons écrit un petit test dans lequel le travail prend jusqu’à 2 ms, tandis que le test attend seulement 1 ms avant de vérifier :

def flaky_timing():
    result = {}
    def work():
        time.sleep(random.uniform(0, 0.002))
        result["done"] = True
    threading.Thread(target=work).start()
    time.sleep(0.001)        # hope it has finished
    assert result.get("done")

La solution consiste à attendre la condition réelle, avec une limite supérieure généreuse :

def fixed_timing():
    result = threading.Event()
    def work():
        time.sleep(random.uniform(0, 0.002))
        result.set()
    threading.Thread(target=work).start()
    assert result.wait(timeout=1)   # continues as soon as it is ready

Nous avons exécuté chaque version 200 fois :

Le résultat va bien au-delà de la simple fiabilité. La version fixe se déplace au moment où le travail est terminé, elle est donc généralement plus rapide aussi. Une veille plus longue entraînerait des échecs moins fréquents de la première version, mais chaque exécution serait alors plus lente et elle pourrait toujours échouer sur une machine CI occupée.

Dans les tests de navigateur, le même principe s’applique. Utilisez l’attente automatique de Playwright, ou les Selenium waits explicites, au lieu de time.sleep :

# Playwright: retries until true or a timeout is reached
expect(page.get_by_text("Order placed")).to_be_visible()

# Selenium: an explicit wait for a condition
WebDriverWait(driver, 10).until(
    EC.visibility_of_element_located((By.ID, "confirmation"))
)

Cause 2 : État partagé et ordre de test

Lorsque les tests partagent des données, l’un peut en affecter un autre et le résultat dépend de l’ordre dans lequel ils sont exécutés. Ces deux tests utilisent une liste partagée :

store = []

def test_add():
    store.append("x")
    assert len(store) == 1

def test_empty():
    assert store == []

Notre exécution l’a confirmé, et c’est pourquoi une suite peut durer des mois, puis s’interrompre lorsque quelqu’un ajoute des exécutions parallèles ou un plugin de classement aléatoire. Le remède est l’isolement :

• Donnez à chaque test de nouvelles données, en utilisant un appareil qui les configure et les nettoie. Notre tutoriel pytest montre comment procéder.
• Créez des enregistrements uniques, tels qu’un e-mail avec un suffixe aléatoire, à la place d’un « utilisateur test » partagé.
• Enveloppez les tests de base de données dans une transaction et annulez-la, là où votre configuration le permet.
• Exécutez régulièrement des tests dans un ordre aléatoire, afin que ces problèmes apparaissent tôt.

Cause 3 : dates, fuseaux horaires et caractère aléatoire

Un test qui réussit toute la semaine peut échouer un samedi, à minuit ou le dernier jour du mois. Faites du temps une entrée, plutôt que de lire l’horloge dans votre logique :

def is_weekend(today=None):
    today = today or datetime.date.today()
    return today.weekday() >= 5

is_weekend(datetime.date(2026, 11, 7))   # True  (a Saturday)
is_weekend(datetime.date(2026, 11, 9))   # False (a Monday)

Ces tests donnent la même réponse n’importe quel jour. De même, définissez une valeur de départ fixe pour les valeurs aléatoires dans les tests et enregistrez-la lorsque vous utilisez des données aléatoires afin de pouvoir reproduire un échec. Ne supposez pas un ordre particulier à partir d’ensembles, de dictionnaires provenant de sources externes ou de requêtes de base de données sans ORDER BY.

Cause 4 : Sélecteurs fragiles

Un test qui trouve un bouton avec div:nth-child(3) > span s’interrompt avec tout ajustement de mise en page et peut échouer uniquement pour certaines tailles d’écran ou variantes. Préférez les localisateurs basés sur ce que voient les utilisateurs ou des attributs de test dédiés. Notre guide des Localisateurs de dramaturges explique l’ordre dans lequel les essayer. Les animations sont une autre source fréquente de problèmes, pensez donc à les désactiver dans les environnements de test.

Cause 5 : services et réseaux externes

Si un test fait appel à un véritable fournisseur de paiement ou à une API tierce, son résultat dépend de la disponibilité et des limites de débit de quelqu’un d’autre. Moquez-vous de ces appels pour la plupart des tests et conservez un petit nombre de vérifications de contrat distinctes par rapport au service réel, afin de toujours savoir s’il change. Notre guide sur les tests unitaires et d’intégration explique comment les diviser.

Comment diagnostiquer un test floconneux

1. Confirmez-le. Exécutez le test plusieurs fois sans modifications. Avec pytest, une simple boucle shell fonctionne, et un plugin tel que pytest-repeat vous donne --count=100.
2. Enregistrez les preuves. Enregistrez les journaux, les captures d’écran et les traces pour chaque échec. La visionneuse de traces de Playwright est particulièrement utile ici.
3. Insistez sur les conditions. Exécutez-le avec un processeur limité, en parallèle ou dans un ordre aléatoire. Le faire échouer plus souvent facilite l’étude.
4. Testez-le seul. S’il réussit toujours seul mais échoue dans la suite, suspectez un état partagé.
5. Recherchez des modèles. Vérifiez quelles machines, heures de la journée et tests voisins sont impliqués.
6. Vérifiez le produit. Demandez honnêtement s’il s’agit d’une véritable condition de concurrence critique dans votre application.

Les tentatives automatiques sont-elles une solution ?

Les nouvelles tentatives constituent un filet de sécurité utile à court terme et ne constituent pas un remède. Une seule nouvelle tentative automatique dans CI peut faire avancer le travail pendant que vous enquêtez, mais un test qui nécessite une nouvelle tentative pour réussir vous dit toujours quelque chose. Pire encore, un véritable bug de produit intermittent qui échoue 20 % du temps passera généralement inaperçu après une nouvelle tentative.

Utilisez les tentatives avec ces règles : limitez-les à une ou deux, enregistrez chaque test qui en nécessitait une et traitez cette liste comme votre liste de tâches. Un test signalé comme « réussi après nouvelle tentative » devrait être considéré comme un problème à étudier, et non comme un succès.

Un processus d’équipe pour des tests irréguliers

1. Mesurer. Suivez les tests qui échouent, puis transmettez le même commit. De nombreux outils CI et rapporteurs de tests peuvent le montrer.
2. Quarantaine. Déplacez un test irrégulier confirmé hors de l’exécution bloquante, afin qu’il cesse de perturber tout le monde, mais continuez à l’exécuter et à le suivre.
3. Attribuez un propriétaire et une date limite. Une quarantaine sans date limite devient tout simplement un cimetière.
4. Corriger ou supprimer. Si un test ne vaut pas la peine d’être corrigé, supprimez-le et vérifiez que sa couverture existe toujours ailleurs.
5. Prévenir. Exécutez de nouveaux tests plusieurs fois avant de fusionner. Un test qui échoue une fois sur cinquante est mieux réussi maintenant que dans six mois.

Traitez un test irrégulier comme un bug prioritaire, et non comme un bruit de fond. La gravité et la priorité s’appliquent également ici, comme indiqué dans gravité vs priorité. Si la fragilité est répandue, renseignez-vous sur les erreurs d’automatisation des tests plus larges et demandez-vous si vous avez trop de tests au niveau du navigateur.

Pour conclure

Les tests irréguliers semblent aléatoires, mais ils le sont rarement. Presque tout le monde se résume à une hypothèse sur le temps, l’ordre, les données ou l’environnement qui n’est pas toujours vraie. Choisissez le test qui échoue le plus souvent dans votre pipeline cette semaine. Exécutez-le cinquante fois, trouvez l’hypothèse et corrigez-la pour de bon. Une vraie solution apprend à une équipe que plus d’une centaine de rediffusions le feront.

Questions fréquentes

Continuez à apprendre