Réponse.

Les tests flaky sont des tests qui peuvent réussir ou échouer sans modifications du code, en raison de facteurs externes aléatoires. Ils sapent la confiance dans l'automatisation et compliquent les processus CI/CD.

Historique de la question : La tension autour des tests flaky a émergé avec la prolifération des tests E2E, d'intégration et UI, lorsque la stabilité de l'environnement et des services dépendants n'était pas garantie. Au début, ces échecs étaient ignorés ou "redémarrés manuellement".

Problème :

Les tests flaky rendent l'exécution automatique des tests peu fiable.
Les développeurs commencent à ignorer de véritables échecs, les considérant comme faux positifs.
Le temps de maintenance des tests augmente et une analyse manuelle des résultats instables est nécessaire.

Solution :

Gestion séparée des tests flaky. Les étiqueter (par exemple, @FlakyTest) ou les rassembler dans une catégorie distincte.
Réexécution automatique. En cas d'échec du test, le répéter X fois — s'il échoue pas toujours, le marquer comme instable.
Analyse des causes d'instabilité : utilisation des logs, des instantanés d'état, surveillance des ressources (par exemple, réseau instable, files d'attente ou fonctionnement du GC).
Correction progressive : travailler sur l'environnement de test, simplifier les scénarios, simuler les dépendances instables.

Exemple de code pour la réexécution automatique :

import pytest
@pytest.mark.flaky(reruns=3, reruns_delay=2)
def test_random_fail():
    ... # code du test

Caractéristiques clés :

Il est important de distinguer les tests flaky des véritables échecs.
Il ne faut pas simplement "réexécuter tout" — les véritables bugs ne doivent pas être ignorés.
Le statut des tests est régulièrement analysé et documenté, et non dissimulé.

Questions pièges.

Les tests flaky sont-ils toujours un problème d'infrastructure ?

Non, les flaky peuvent être causés par des erreurs de logique métier, des conditions de course dans le code, de l'asynchronisme ou un mauvais traitement du temps.

Est-il suffisant de simplement redémarrer les tests échoués ?

Non, les réexécutions masquent simplement le problème. Il est nécessaire de rechercher et de résoudre la cause.

Faut-il supprimer tous les tests instables ?

Non, ils doivent être temporairement isolés et les causes corrigées, plutôt que d'être simplement exclus définitivement.

Erreurs typiques et anti-patterns

Ignorer les tests flaky, ce qui entraîne le passage à côté de bugs graves.
Réexécution massive sans analyse des causes.
Marquer des tests importants comme flaky sans action pour les corriger.

Exemple de la vie

Cas négatif

Dans le projet, les tests flaky étaient simplement étiquetés et plus jamais touchés, considérant le problème comme "irréel".

Avantages :

Réduction du nombre de faux "rouges" dans les builds.

Inconvénients :

De véritables bugs passent en production.
Vérification manuelle constante des résultats.

Cas positif

Pour chaque test instable, un réexamen automatique et une gestion interne de l'instabilité ont été mis en place. Des revues régulières des causes étaient effectuées et les bugs étaient corrigés au fur et à mesure de leur accumulation.