Co jsou nestabilní testy (flaky tests) a jak se s nimi vypořádat?

Question

Accepted Answer

**Nestabilní testy (flaky tests)** jsou testy, které **procházejí nebo selžou nekonzistentně** bez změn kódu — někdy procházejí, někdy selžou na stejném kódu. Jedná se o vážný problém, protože podkopávají důvěru v testovací sadu. Pochopení jejich příčin a řešení je důležité.

## Co jsou nestabilní testy a proč jsou škodlivé

```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.
```

## Běžné příčiny

```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
```

## Opravy a správa nestabilních testů

```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)
```

## Proč je to důležité

Pochopení nestabilních testů a způsobu jejich řešení je důležité, protože **nestabilní testy jsou vážný, běžný problém, který podkopává hodnotu celé testovací sady**, takže se jedná o cenné praktické znalosti.

Nestabilní test (procházení nebo selhání nekonzistentně na stejném kódu) je zvlášť škodlivý, protože **podkopává důvěru**: když testy selžou nepředvídatelně, lidé začínají ignorovat selhání ("je to jen nestabilní"), což znamená, že **skutečná selhání jsou také přehlédnuta** — nestabilita tak snižuje důvěru v celou sadu, což ji může učinit horší než zbytečnou.

Pochopení této škody motivuje k vážnému přístupu k nestabilitě.

Pochopení **běžných příčin** — **problémy s časováním/asyncem** (race conditions, nesprávné čekání na asynchronní operace, libovolné sleepy — hlavní příčina zejména u UI/E2E testů), **závislost na pořadí** (testy závislé na sobě nebo sdíleném stavu), **externí závislosti** (skutečná síť/služby s jejich výkyvy a výpadky), **nedeterminismus** (čas, náhoda, časová zóna, locale) a **problémy prostředí** (zbylý stav, souběžnost) — je nezbytné pro diagnostiku nestability.

Pochopení toho, jak **opravit a spravovat** nestabilní testy — oprava kořenových příčin (čekání na podmínky místo sleepů, nezávislost testů a čistota, mockování externích závislostí, kontrola času a náhodnosti), zajištění izolace, **nezálepkování slepým opakováním** (které skrývá problémy), karanténa přetrvávajících nestabilních testů během jejich opravy a zacházení s nestabilitou jako s vážným problémem ke sledování a řešení — odráží správný přístup.

Proto, že nestabilní testy jsou běžný, vážný problém, který podkopává důvěru v testovací sadu a její hodnotu (skutečný problém v mnoha reálných projektech), a protože pochopení jejich příčin a správné manipulace (oprava kořenových příčin, izolace, ne jen opakování) je nezbytné k udržení důvěryhodné testovací sady, je pochopení nestabilních testů cenné, prakticky důležité znalosti — řešení významného reálného problému v testování, důležité pro zachování spolehlivé a důvěryhodné testovací sady a odrážející praktickou zralost k řešení jednoho z nejfrustrujících a nejškodlivějších problémů testování.