Antwoord.

Automatisering van testen begon historisch gezien met het idee om de snelheid te verhogen en de menselijke factor in de controles te verminderen, maar het bleek al snel dat geautomatiseerde tests vaak anders reageren bij elke uitvoering. Herhaalbaarheid (repeatability) en determinisme zijn een van de basisvereisten voor de kwaliteit van autotests, die hetzelfde resultaat moeten geven onder dezelfde omstandigheden.

Problemen ontstaan door impliciete afhankelijkheden: onbetrouwbare testgegevens, niet-synchroniseerde omgevingen, parallelle processen of externe services. Dit leidt tot flaky tests — de resultaten daarvan zijn niet te voorspellen.

Oplossingen zijn gebaseerd op strikte controle van de uitvoeringsomgeving, isolatie van tests, mock/stub-objecten, statische gegevens en reproduceerbare scenario's (bijvoorbeeld het schoonmaken en voorbereiden van de database voor elke test).

Kernkenmerken:

Controle van testgegevens en voorspelbare initiatie van de testomgeving.
Isolatie van tests van elkaar en het vermijden van afhankelijkheden tussen tests.
Gebruik van Mock/Stub-objecten voor het omgaan met onbetrouwbare of externe services.

Misleidende vragen.

Wat te doen als een flaky test alleen in CI optreedt, terwijl het lokaal stabiel is?

Dit heeft bijna altijd te maken met verschillen in omgevingen: versies van afhankelijkheden, snelheid van infrastructuur, parallelisme, configuratie van het besturingssysteem of de volgorde van testuitvoering. De oplossing is om de CI-omgeving zo dicht mogelijk bij de dev-machine te brengen (Docker, gelijke seed-waarden, configuratie van setUp/tearDown in tests).

Kunnen parameterized tests volledig deterministisch worden beschouwd als de gegevens uit de database komen?

Nee. Zelfs als de basisgegevens overeenkomen, kan de database tussen tests of tussen releases veranderen. Voor ware determinisme moeten de gegevens expliciet worden voorbereid en gewist in elke test.

Zal het gebruik van sleep om te wachten op het laden van elementen het probleem van onbetrouwbare UI-tests oplossen?

Nee. Sleep maskeert slechts het probleem en vertraagt de uitvoering van tests. Het is correct om expliciete wachttijden (Explicit Waits) te gebruiken, die wachten op specifieke voorwaarden in plaats van een vaste tijd.

Typische fouten en anti-patronen

Gebruik van "magische" getallen en vertragingen in plaats van correcte synchronisatie.
Afhankelijkheid tussen tests of wijzigingen in de omgeving die niet worden teruggedraaid tussen tests.
Vermenging van testgegevens tussen scenario's.

Voorbeeld uit het leven

Negatieve casus

In een project werden UI-tests uitgevoerd op een omgeving die niemand na handmatige tests schoonmaakte. Om de paar nachten faalden de tests met "random" fouten die lokaal niet voorkwamen. Het team voegde sleep toe aan de tests en negeerde de flaky-problemen.

Pluspunten:

Er hoefde niet veel tijd te worden besteed aan het grondig oplossen van het probleem.
Tests vonden soms nog steeds bugs.

Minpunten:

Tijdverlies door herhaalde uitvoeringen.
Valse negatieve resultaten demotiveerden ingenieurs.
Rapporten werden overspoeld met ruis, echte regressie kon worden gemist.

Positieve casus

Na de komst van een ervaren DevOps-engineer implementeerde het team scripts voor het resetten en initiëren van testgegevens, voegden ze mockservices toe voor onbetrouwbare integraties en begonnen ze tests in containers uit te voeren. Flaky tests verdwenen bijna geheel.