Antwort.

Der Mechanismus des Wiederholens von Tests (Retry) wird eingeführt, um die Stabilität der Testpipeline zu erhöhen und gegen flüchtige automatisierte Tests zu kämpfen, erfordert jedoch einen vernünftigen Ansatz.

Geschichte des Problems Entstand als Workaround für vorübergehende infrastrukturelle oder flüchtige Fehler, die nicht mit Fehlern der Anwendung zusammenhängen (instabiles Umfeld, Netzwerkprobleme, zufällige API-Timeouts). Viele CI/CD-Systeme unterstützen mittlerweile eingebautes Retry.

Problem Übermäßiges oder unkontrolliertes Retry kann echte Bugs verbergen oder Abstürze zu "einfachen vorübergehenden Phänomenen" machen. Es entstehen falsch positive Ergebnisse: der Test scheint bestanden zu haben, aber der Bug ist weiterhin vorhanden.

Lösung Aktivieren Sie Retry nur für instabile oder von externen Abhängigkeiten abhängige Tests, verwenden Sie Tags oder Marker. Fester Wiederholungsgrenze (1-2 Mal). Protokollieren Sie alle Abstürze und Erfolge der Wiederholungen zur Analyse der Ursachen für das Scheitern.

import pytest

@pytest.mark.flaky(reruns=2, reruns_delay=5)
def test_external_api():
    # Ein Test, der aufgrund von API-Instabilität fehlschlagen kann
    ...

Wichtige Merkmale:

Punktuelle und bewusste Anwendung
Immer die Ursachen von Wiederholungen analysieren
Bugs der Anwendung nicht maskieren, sondern nur infrastrukturelle/flüchtige

Fangfragen.

Kann man alle automatisierten Tests im Pipeline wiederholt ausführen?

Das ist eine schlechte Praxis: sowohl echte Bugs als auch architektonische Probleme von Tests werden verborgen. Retry ist der letzte Ausweg für bestimmte Arten von Tests.

Was tun, wenn der Test nach 3 Wiederholungen immer noch nicht besteht?

Den Test abbrechen und einen Bug zur Instabilität/Untersuchung eröffnen – so werden tricky Fehler erkannt, die Refactoring erfordern.

Wenn der Test beim zweiten Versuch besteht – ist alles gut?

Nein, der einzige korrekte Zustand ist das stabile Bestehen beim ersten Versuch. Bestehen beim zweiten Versuch ist ein Indikator für ein Problem (flüchtig oder infrastrukturell).

Typische Fehler und Anti-Pattern

Unkontrollierte Anwendung von Retry, die Bugs verbirgt
Fehlende Analyse der Ursachen für Abstürze
Verwendung von Retry anstelle der Behebung echter Probleme

Beispiel aus dem Leben

Negativer Fall

Für die gesamte Jenkins-Pipeline wurde globales Retry auf zwei Ausführungen aktiviert. Nach einem Monat wurden Bugs aufgrund von Race Conditions im Code verschleiert, und das Team glaubte, dass die "Qualität in Ordnung" sei. Das Produkt begann plötzlich aufgrund derselben Bugs in der Produktion abzustürzen.

Vorteile:

Es gab grüne Pipelines

Nachteile:

Bugs der Anwendung wurden nicht rechtzeitig identifiziert
Bei Untersuchungen war es schwer, die Quelle der Unzuverlässigkeit zu verstehen

Positiver Fall

Für die Testkategorie mit externen APIs wurde Retry nur für diese (basierend auf Tags) konfiguriert. Alle anderen Tests bestehen strikt beim ersten Versuch. Anhand von Protokollen untersucht das Team wiederkehrende Fehlversuche und behält sie im Blick.