Ga naar de inhoud

Een flaky test herkennen en uit de suite halen

  • door

Een test die om de beurt faalt zonder dat de productiecode veranderde, is geen strenge test. Zij is ruis, en ruis leert een team de rode build te negeren. In Eindhoven is dat het moment waarop QA-automation haar naam verliest: de suite staat aan, niemand gelooft haar. Dit stuk geeft een volgorde om zo’n test te herkennen en te verwijderen of te repareren, aansluitend op QA Automation en op het vakje in de Checklists dat een groene run alleen telt wanneer hij herhaalbaar is.

Checklist en testrapport op tafel bij het beoordelen van een onstabiele test in Eindhoven
Eerst de oorzaak benoemen, dan pas een retry. Een retry zonder oorzaak verplaatst de flake naar morgen.

Herken de flake aan het patroon, niet aan het humeur. Dezelfde test slaagt lokaal en faalt in CI, of slaagt bij de tweede run zonder codewijziging. De foutmelding wisselt tussen een time-out en een ontbrekend element. Twee tests raken dezelfde gebruiker of dezelfde order. Een slaap van twee seconden “lost het op” tot de runner trager is. Schrijf dat patroon in het ticket voordat u de test herschrijft. Zonder patroon repareert u een gok.

De oorzaken zijn voorspelbaar. Een selector die op een animatie wacht in plaats van op een toestand. Een klok die in de test hard staat en op de runner niet. Data die een vorige test achterliet. Een externe dienst die in de testomgeving soms traag is en die u als productgedrag behandelt. Parallelle jobs zonder isolatie. Elk van die oorzaken heeft een andere reparatie. Een algemene retry verbergt ze alle vijf en maakt de suite langzamer.

Repareer in deze volgorde. Isoleer de data, zodat geen andere test de rij nodig heeft. Vervang slaap door een voorwaarde die het product zelf toont. Haal de afhankelijkheid van een externe dienst achter een contract dat u beheerst, of markeer de test als niet-blokkerend zolang die dienst geen deel van uw releasecriterium is. Blijft de test daarna flaky, haal haar uit de blokkerende job. Een overgeslagen test die zichtbaar is, is eerlijker dan een rode die iedereen wegklikt. Zet op de checklist dat dit pad handmatig wordt gedaan tot de test terug mag.

Meet daarna een week. Draait de test twintig keer groen op een schone runner, dan mag zij terug in de blokkerende set. Eén groene avond telt niet. Teams die flakes verzamelen in een lijst “ooit repareren” zonder eigenaar, bouwen een tweede backlog die niemand opent. Eén eigenaar, één week, of de test gaat eruit. Dat is streng en het is de enige manier waarop een lampje op de pipeline weer iets betekent wanneer u vrijdag op Strijp-S of bij uw eigen release beslist. Een lijst zonder datum is uitstel, en uitstel is hoe een suite haar gezag verliest.