Wat zijn flaky tests en hoe ga je ermee om?

Question

Accepted Answer

**Flaky tests** zijn tests die **inconsistent slagen of mislukken** zonder codewijzigingen — soms slagen, soms mislukken op dezelfde code. Ze vormen een ernstig probleem omdat ze het vertrouwen in de testuite ondermijnen. Het begrijpen van hun oorzaken en oplossingen is belangrijk.

## Wat flaky tests zijn en waarom ze schadelijk zijn

```text
A FLAKY test gives INCONSISTENT results (pass sometimes, fail other times) on the SAME code:
  → harmful: ERODES TRUST — people start ignoring failures ("oh, it's just flaky") →
    real failures get missed too
  → waste time on false alarms / re-runs; break CI; reduce confidence in the whole suite
→ Flaky tests are worse than no test if they make people distrust all tests.
```

## Veelvoorkomende oorzaken

```text
✗ TIMING / async → race conditions; not waiting properly for async operations (a top cause
  in UI/E2E tests); arbitrary sleeps
✗ ORDER DEPENDENCE → tests depending on each other / shared mutable state
✗ EXTERNAL dependencies → real network/services (network blips, rate limits, downtime)
✗ NON-DETERMINISM → time/dates, randomness, timezone, locale
✗ Test ENVIRONMENT → leftover state, uncleaned data, concurrency/parallelism issues
```

## Flaky tests repareren en beheren

```text
✓ Fix the ROOT CAUSE: wait for conditions (not sleeps); make tests INDEPENDENT and clean
  up state; MOCK external dependencies; control time/randomness (inject them)
✓ Ensure proper isolation (no shared state, no order dependence)
✓ Don't just RETRY blindly (it hides the problem) — investigate and fix
✓ QUARANTINE persistently flaky tests (isolate so they don't block) WHILE fixing them
✓ Treat flakiness seriously — track and address it (it degrades the whole suite)
```

## Waarom het belangrijk is

Het begrijpen van flaky tests en hoe ermee om te gaan is belangrijk omdat **flaky tests een ernstig, veelvoorkomend probleem vormen dat de waarde van een hele testuite ondermijnt**, dus het is waardevolle praktische kennis.

Een flaky test (inconsistent slaagde of mislukkende op dezelfde code) is vooral schadelijk omdat het **vertrouwen ondermijnt**: wanneer tests onvoorspelbaar mislukken, beginnen mensen fouten te negeren ("het is gewoon flaky"), wat betekent dat **echte fouten ook gemist worden** — dus flakiness vermindert het vertrouwen in de hele suite, waardoor het potentieel erger kan zijn dan waardeloos.

Het begrijpen van deze schadelijkheid motiveert om flakiness serieus te nemen.

Het begrijpen van de **veelvoorkomende oorzaken** — **timing-/async-problemen** (race conditions, niet goed wachten op async-operaties, willekeurige sleeps — een topveroorzaker vooral in UI/E2E-tests), **ordersafhankelijkheid** (tests die van elkaar of gedeelde state afhangen), **externe afhankelijkheden** (echte netwerk-/services met hun storingen en downtime), **non-determinisme** (tijd, willekeur, timezone, locale), en **omgevingsproblemen** (resterende state, concurrency) — is noodzakelijk om flakiness te diagnosticeren.

Het begrijpen hoe ze **repareren en beheren** — worteloorzaken repareren (wachten op voorwaarden in plaats van sleeps, tests onafhankelijk en schoon maken, externe afhankelijkheden mocken, tijd en willekeur controleren), isolatie garanderen, **niet blindelings opnieuw proberen** (wat problemen verbergt), persistente flaky tests in quarantaine plaatsen terwijl je ze reparaert, en flakiness als een ernstig probleem behandelen om bij te houden en aan te pakken — weerspiegelt de juiste aanpak.

Omdat flaky tests een veelvoorkomend, ernstig probleem vormen dat vertrouwen in en de waarde van een testuite ondermijnt (een echt probleem in veel echte projecten), en omdat het begrijpen van hun oorzaken en juiste verwerking (worteloorzaken repareren, isolatie, niet zomaar opnieuw proberen) noodzakelijk is om een betrouwbare testuite te behouden, is het begrijpen van flaky tests waardevolle, praktisch-belangrijke kennis — die een belangrijk echt-wereldprobleem aanpakt, belangrijk voor het behoud van een betrouwbare en vertrouwde testuite, en die de praktische volwassenheid weerspiegelt om met een van de meest frustrerende en schadelijke problemen van testen om te gaan.