Mik azok a flaky tesztek és hogyan kezelhetők?

Question

Accepted Answer

**Flaky tesztek** olyan tesztek, amelyek **inkonzisztensen mennek át vagy buknak meg** kódváltoztatások nélkül — néha átmennek, néha ugyanazon a kódon megbuknak. Súlyos probléma, mivel aláássa a tesztcsomag megbízhatóságát. Fontos megérteni az okaikat és azok megoldásait.

## Mi a flaky teszt és miért káros

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

## Gyakori okok

```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 tesztek javítása és kezelése

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

## Miért fontos

A flaky tesztek megértése és kezelése fontos, mert **a flaky tesztek komoly, gyakori probléma, amely aláásza az egész tesztcsomag értékét**, így gyakorlati értékkel bíró tudás.

Egy flaky teszt (inkonzisztensen megy át vagy bukik meg ugyanazon a kódon) különösen ártalmas, mert **aláássa a bizalmat**: amikor a tesztek kiszámíthatatlanul buknak meg, az emberek elkezdik figyelmen kívül hagyni a hibákat ("csak flaky"), ami azt jelenti, hogy **az igazi hibákat is elszalaszthatjuk** — így a flakiness csökkenti az egész csomag feletti megbízást, potenciálisan hasznosabbá téve azt, mintha egyáltalán nem lenne.

E kár megértése motiválja, hogy komolyan kezeljük a flakiness-t.

A **gyakori okok** megértése — **időzítési/aszinkron problémák** (versenyhelyzetek, nem megfelelő várakozás az aszinkron műveletre, önkényes sleepek — a fő ok, különösen az UI/E2E teszteknél), **sorrend függőség** (tesztek egymástól vagy közös állapottól függenek), **külső függőségek** (valódi hálózat/szolgáltatások problémáikkal és leállásaikkal), **nem-determinizmus** (idő, véletlen, időzóna, területi beállítások), és **környezeti problémák** (maradt állapot, párhuzamosság) — szükséges a flakiness diagnosztizálásához.

A **javítás és kezelés** módjának megértése — az alapvető okok kijavítása (feltételekre való várakozás sleepek helyett, tesztek függetlenségének és tisztaságának biztosítása, külső függőségek mockolása, idő és véletlenség szabályozása), izoláció biztosítása, **ne csak vakon újrapróbálkozzunk** (amely elrejti a problémákat), tartósan flaky tesztek karanténba helyezése a javítás közben, és a flakiness komoly problémaként való kezelése, amit követni és megoldani kell — a helyes megközelítést tükrözi.

Mivel a flaky tesztek gyakori, súlyos probléma, amely aláássa a tesztcsomag megbízhatóságát és értékét (valós probléma számos valódi projektben), és mivel okaikat és helyes kezelésüket (alapvető okok kijavítása, izoláció, nem csak újrapróbálkozás) megérteni szükséges a megbízható tesztcsomag fenntartásához, a flaky tesztek megértése értékes, gyakorlatilag fontos tudás — egy szignifikáns valós problémát kezel, fontos a tesztcsomag megbízhatóságának és megbízhatóságának fenntartásához, és tükrözi a gyakorlati érettséget az egyik tesztelés legfrusztráltabb és legkárosabb problémájának kezeléséhez.