Antwoord.

Flaky tests zijn tests die slagen of falen zonder veranderingen in de code, door willekeurige externe factoren. Ze ondermijnen het vertrouwen in automatisering en bemoeilijken CI/CD-processen.

Geschiedenis van de kwestie: De spanning met flaky tests ontstond met de opkomst van massale E2E-, integratie- en UI-tests, wanneer de stabiliteit van de omgeving en afhankelijkheid van services niet gegarandeerd was. In het begin werden zulke fouten genegeerd of "handmatig herstart".

Probleem:

Flaky tests maken de automatische uitvoering van tests onbetrouwbaar.
Ontwikkelaars beginnen echte fouten te negeren, beschouwend als valse.
De onderhoudstijd van tests groeit en handmatige analyse van instabiele resultaten is nodig.

Oplossing:

Apart bijhouden van flaky tests. Labelen (bijvoorbeeld, @FlakyTest) of apart categoriseren.
Automatisch heruitvoeren. In het geval van een falende test herhaal deze X keer - als het niet altijd faalt, markeer de test als instabiel.
Analyse van instabiliteitsredenen: gebruik van logs, snapshots van de status, monitoring van resources (bijvoorbeeld instabiel netwerk, wachtrijen of werking van GC).
Geleidelijke oplossing: werken met de testomgeving, vereenvoudigen van scenario's, mocken van instabiele afhankelijkheden.

Voorbeeldcode voor auto-retry:

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

Belangrijke kenmerken:

Het is belangrijk om flaky tests van echte fouten te scheiden.
Het is niet verstandig om gewoon "alles opnieuw uit te voeren" - echte bugs mogen niet worden gemist.
De status van de test moet regelmatig worden geanalyseerd en gedocumenteerd, en niet stilzwijgend worden behandeld.

Misleidende vragen.

Zijn flaky tests altijd een probleem van infrastructuur?

Nee, flaky tests kunnen worden veroorzaakt door fouten in de bedrijfslogica, racecondities in de code, asynchroniciteit of onjuiste tijdsverwerking.

Is het voldoende om gewoon falende tests opnieuw uit te voeren?

Nee, retries verbergen alleen het probleem. Het is nodig om de oorzaak te vinden en op te lossen.

Moet je alle instabiele tests verwijderen?

Nee, ze moeten tijdelijk worden geïsoleerd en de oorzaken moeten worden verholpen en niet gewoon voor altijd worden uitgesloten.

Typische fouten en anti-patronen

Het negeren van flaky tests, wat leidt tot het missen van ernstige bugs.
Massale retries zonder analyse van de redenen.
Het labelen van belangrijke tests als flaky zonder actie te ondernemen om ze te verbeteren.

Voorbeeld uit het leven

Negatieve casus

In het project werden flaky tests gewoon gelabeld en verder niet meer aangeraakt, beschouwend als "onoplosbaar".

Voordelen:

Vermindering van het aantal valse "rode" builds.

Nadelen:

Echte bugs worden naar productie gestuurd.
Constante handmatige controle van resultaten.

Positieve casus

Voor elke instabiele test werd een automatische retry en interne registratie van instabiliteit ingevoerd. Regelmatige gezamenlijke evaluatie van de redenen vond plaats en bugs werden verholpen naarmate ze zich opstapelden.