Kaj so nestabilni testi in kako se jih lotite?

Question

Accepted Answer

**Nestabilni testi** so testi, ki **nehote prehajajo ali padajo** brez spreminjanja kode — včasih se uspešno izvršijo, včasih ne na isti kodi. So resen problem, ker zmanjšajo zaupanje v testni paket. Razumevanje njihovih vzrokov in rešitev je pomembno.

## Kaj so nestabilni testi in zakaj so škodljivi

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

## Pogosti vzroki

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

## Odpravljanje in upravljanje nestabilnih testov

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

## Zakaj je to pomembno

Razumevanje nestabilnih testov in kako se jih lotiti je pomembno, ker so **nestabilni testi resen in pogost problem, ki zmanjša vrednost celotnega testnega paketa**, zato je to dragoceno praktično znanje.

Nestabilen test (ki nehote prehaja ali pada na isti kodi) je posebej škodljiv, ker **zmanjša zaupanje**: ko testi nehote padejo, ljudje začnejo zanemarjati napake ("je samo nestabilen"), kar pomeni, da se **resne napake spregledajo** — zato nestabilnost zmanjša zaupanje v celoten paket, kar ga lahko naredi celo slabšega kot neuporabnega.

Razumevanje te škode motivira resno odnosnost do nestabilnosti.

Razumevanje **pogostih vzrokov** — **težave s časovanjem/asinkrionostjo** (race conditions, nepravilno čakanje na asinkrone operacije, poljubne zakasnitve — glavna težava zlasti pri UI/E2E testih), **odvisnost od vrstnega reda** (testi, odvisni drug od drugega ali skupnega stanja), **zunanje odvisnosti** (resnična omrežja/storitve z njihovimi motnjami in izpadi), **nedeterminizem** (čas, naključnost, časovni pas, lokalizacija) in **težave s okoljem** (ostanki stanja, sočasnost) — je potrebno za diagnozo nestabilnosti.

Razumevanje, kako **odpraviti in upravljati** nestabilne teste — odpravljanje temeljnih vzrokov (čakanje na pogoje namesto zakasnitev, ločevanje testov in čiščenje, simulacija zunanjih odvisnosti, nadzor časa in naključnosti), zagotavljanje izolacije, **ne slepega ponovnega poskusa** (ki skriva probleme), karanteno vztrajnih nestabilnih testov med odpravljanjem napak in obravnava nestabilnosti kot resnega problema za spremljanje in reševanje — odraža pravilen pristop.

Ker so nestabilni testi pogost in resno resen problem, ki zmanjšuje zaupanje v testni paket in njegovo vrednost (pravi problem v mnogih dejanskih projektih), in ker je razumevanje njihovih vzrokov in pravilnega ravnanja (odpravljanje temeljnih vzrokov, izolacija, ne le ponavljanje) potrebno za ohranitev zaupanja vrednega testnega paketa, je razumevanje nestabilnih testov dragoceno, praktično važno znanje — obravnava както najpogostejšega kot najbolj škodljivega testnega problema, pomembno za ohranjanje zanesljivega in zaupanja vrednega testnega paketa ter odraža praktično zrelost za ravnanje z enim najfrustracijocih in najbolj škodljivih problemov testiranja.