Réponse.

Le mécanisme de réexécution du test (retry) est mis en place dans le but d'améliorer la stabilité de la chaîne de tests et de lutter contre les autotests flaky, mais nécessite une approche réfléchie.

Historique de la question Est apparu comme un contournement pour des erreurs infrastructurales temporaires ou flaky, non liées aux erreurs de l'application (environnement instable, problèmes de réseau, délais d'attente aléatoires d'API). De nombreux systèmes CI/CD prennent désormais en charge le retry intégré.

Problème Un retry excessif ou incontrôlé peut masquer de véritables bugs ou transformer des échecs en "simplement des phénomènes temporaires". Des résultats faussement positifs apparaissent : apparemment, le test a réussi, mais le bug est toujours présent.

Solution N'activez le retry que pour des tests instables ou dépendants d'externes, utilisez des tags ou des marqueurs. Limite fixe de réexécutions (1-2 fois). Enregistrez tous les échecs et succès des réexécutions pour analyser les raisons des défaillances.

import pytest

@pytest.mark.flaky(reruns=2, reruns_delay=5)
def test_external_api():
    # Test qui peut échouer en raison de l'instabilité de l'API
    ...

Caractéristiques clés :

Appliquer de manière ciblée et consciente
Toujours analyser les raisons des réexécutions
Ne pas masquer les bugs de l'application, mais uniquement ceux d'infrastructure/flaky

Questions pièges.

Peut-on relancer absolument tous les autotests dans la chaîne ?

C'est une mauvaise pratique : cela masque tant les véritables bugs que les problèmes architecturaux des tests. Le retry est un dernier recours pour certains types de tests.

Que faire si, après trois réexécutions, le test ne passe toujours pas ?

Cesser l'exécution et ouvrir un bug sur l'instabilité/enquête - c'est ainsi que l'on identifie des erreurs difficiles qui nécessitent un refactoring.

Si le test passe du deuxième coup - tout va bien ?

Non, le seul état correct est un passage stable du premier coup. Passer du deuxième coup est un indicateur de problème (flaky ou infrastructure).

Erreurs typiques et anti-patrons

Application incontrôlée du retry, masquant des bugs
Absence d'analyse des raisons des échecs
Utilisation du retry au lieu de corriger de réels problèmes

Exemple de la vie

Cas négatif

Pour l'ensemble du pipeline Jenkins, un retry global a été activé pour deux exécutions. Après un mois, les bugs dus à des conditions de concurrence dans le code se sont étalés, et l'équipe pensait que "la qualité était bonne". Le produit a soudainement commencé à tomber en production à cause des mêmes bugs.

Avantages :

Des pipelines verts

Inconvénients :

Les bugs de l'application n’étaient pas détectés à temps
Lors des investigations, il était difficile de comprendre la source de l'instabilité

Cas positif

Pour la catégorie de tests avec des API externes, le retry a été configuré uniquement pour eux (par tags). Tous les autres tests passent strictement du premier coup. Par les logs, l'équipe enquête et enregistre les échecs récurrents.