Antwoord.

Het mechanisme voor het opnieuw uitvoeren van tests (retry) wordt geïmplementeerd om de stabiliteit van de testpipeline te vergroten en om te gaan met flakey autotests, maar vereist een verstandige aanpak.

Geschiedenis van de kwestie Het is ontstaan als een workaround voor tijdelijke infrastructuur- of flakey fouten die niet gerelateerd zijn aan applicatiefouten (instabiele omgeving, netwerkproblemen, toevallige API-timeouts). Veel CI/CD-systemen ondersteunen tegenwoordig ingebouwde retry.

Probleem Overmatige of ongecontroleerde retry kan echte bugs verbergen of fouten omvormen tot "slechts tijdelijke verschijnselen". Dit leidt tot vals positieve resultaten: de test lijkt geslaagd, maar de bug is er nog steeds.

Oplossing Schakel retry alleen in voor instabiele of externe afhankelijke tests, gebruik tags of markeringen. Een vaste limiet voor herhalingen (1-2 keer). Log alle foutmeldingen en successen van herhaalde uitvoeringen voor analyse van de oorzaken van fouten.

import pytest

@pytest.mark.flaky(reruns=2, reruns_delay=5)
def test_external_api():
    # Test die kan falen door onbetrouwbaarheid van de API
    ...

Belangrijke kenmerken:

Pas selectief en bewust toe
Analyseer altijd de oorzaken van herhalingen
Verberg geen bugs in de app, alleen infrastructuur/flaky

Vragen met een twist.

Mag je alle autotests in de pipeline opnieuw uitvoeren?

Dit is een slechte praktijk: zowel echte bugs als architectonische problemen van de tests worden verborgen. Retry is een uiterste maatregel voor sommige soorten tests.

Wat te doen als de test na 3 herhaalde uitvoeringen nog steeds niet slaagt?

Stop de uitvoering en open een bug voor instabiliteit/onderzoek — zo worden tricky fouten aan het licht gebracht die refactoring vereisen.

Als de test de tweede keer slaagt — is alles dan goed?

Nee, de enige correcte toestand is een stabiele uitvoer bij de eerste poging. Slaag bij de tweede poging is een indicator voor een probleem (flakey of infrastructuur).

Veelvoorkomende fouten en anti-patronen

Ongecontroleerd gebruik van retry, wat bugs verbergt
Gebrek aan analyse van de oorzaken van falen
Gebruik van retry in plaats van het oplossen van echte problemen

Voorbeeld uit het leven

Negatief geval

Voor de gehele Jenkins-pipeline werd globale retry voor twee uitvoeringen ingeschakeld. Na een maand werden bugs door race conditions in de code verspreid, terwijl het team geloofde dat "kwaliteit ok" was. Het product begon plotseling te falen in productie door dezelfde bugs.

Voordelen:

Er waren groene pipelines

Nadelen:

Bugs in de app werden niet tijdig ontdekt
Tijdens het graven was het moeilijk om de bron van onbetrouwbaarheid te begrijpen

Positief geval

Voor de categorie tests met externe API's werd retry alleen voor hen ingesteld (op basis van tags). Alle andere tests slagen strikt bij één poging. Aan de hand van de logs onderzoeken de teams en fixeren ze herhaaldelijke fouten.