Kas yra nestabilūs testai ir kaip jų sprendžiate?

Question

Accepted Answer

**Nestabilūs testai** yra testai, kurie **laisvai praeina arba nepavyksta be kodo pasikeitimų** — kartais praeina, kartais nepavyksta tame pačiame kode. Tai rimta problema, nes ji griauna pasitikėjimą testų rinkiniu. Supratimas jų priežastims ir sprendimams yra svarbus.

## Kas yra nestabilūs testai ir kodėl jie žalingi

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

## Dažniausios priežastys

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

## Nestabilių testų taisymas ir valdymas

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

## Kodėl tai svarbu

Supratimas apie nestabilius testus ir kaip su jais elgtis yra svarbus, nes **nestabilūs testai yra rimta, paplitusi problema, kuri sugriauja visos testų rinkinio vertę**, todėl tai yra vertinga praktinė žinių sritis.

Nestabilus testas (laisvai praeina arba nepavyksta tame pačiame kode) yra ypač žalingas, nes jis **griauna pasitikėjimą**: kai testai nepavyksta nenuspėjamai, žmonės pradeda ignoruoti jų nepavykimus ("tai tik nestabilus"), o tai reiškia, kad **tikri nepavykimai yra praleisti** — taip nestabilumas sumažina pasitikėjimą visa rinkiniu, potencialiai padarydamas jį piresniu nei nenaudingą.

Supratimas apie šią žalą motyvuoja rimtai žiūrėti į nestabilumą.

Supratimas apie **dažniausias priežastis** — **laiko/asinkroninio problemos** (lenktynės, netinkama asinkronių operacijų laukimas, sąžiningos pauzės — populiariausias priežastis, ypač UI/E2E testuose), **priklausomybė nuo eiliškumo** (testai priklausantys vienas nuo kito arba bendrai būsenai), **išorinės priklausomybės** (realūs tinklo/paslaugų svyravimai ir neleistinaini laikaini), **nedeterminizmas** (laikas, atsitiktinumas, laiko juosta, lokalė), ir **aplinkos problemos** (likutinė būsena, vienuotinumas) — yra būtina diagnozavus nestabilumą.

Supratimas, kaip **taisyti ir valdyti** juos — pataisyti šakniniu priežastis (laukti sąlygų vietoj pauzių, daryti testus nepriklausomus ir grynus, naudoti išorines priklausomybes, kontroliuoti laiką ir atsitiktinumą), užtikrinti izoliavimą, **ne aklosai kartoti bandymus** (kurie slepia problemas), karantininuoti nuolat nestabilius testus kol jie taisomi, ir traktuoti nestabilumą kaip rimtą klausimą sekti ir spręsti — atspindi teisingą požiūrį.

Kadangi nestabilūs testai yra dažna, rimta problema, kuri griauna pasitikėjimą ir testų rinkinio vertę (reali problema daugelyje realių projektų), ir kadangi supratimas jų priežastims ir tinkamas jų tvarkymas (šaknies priežastys, izoliacija, ne tik kartojimas) yra būtinas patikimo testų rinkinio išlaikymui, supratimas apie nestabilius testus yra vertinga, praktiškai svarbi žinių sritis — sprendžiant svarbią realiojo pasaulio testų problemą, svarbią testų rinkinio patikimumo išlaikymui ir atspindintį praktinį subrendimą tvarkant vieną iš testavimo labiausiai dėl pykčio ir žalingiausių problemų.