Hvad er ustabile tests, og hvordan håndterer du dem?

Question

Accepted Answer

**Ustabile tests** er tests, der **består eller fejler usammenhængende** uden kodeændringer — nogle gange består de, nogle gange fejler de på den samme kode. Det er et alvorligt problem, fordi det udhulter tilliden til testsuiten. Det er vigtigt at forstå deres årsager og løsninger.

## Hvad ustabile tests er, og hvorfor de er skadelige

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

## Almindelige årsager

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

## Rettelse og håndtering af ustabile tests

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

## Hvorfor det betyder noget

At forstå ustabile tests og hvordan man håndterer dem, er vigtig, fordi **ustabile tests er et alvorligt, almindeligt problem, der undergraver værdien af en hel testsuite**, så det er værdifuld praktisk viden.

En ustabil test (som består eller fejler usammenhængende på den samme kode) er særligt skadelig, fordi den **udhulter tilliden**: når tests fejler uforudsigeligt, begynder folk at ignorere fejlmeldinger ("det er bare ustabilt"), hvilket betyder, at **rigtige fejl også bliver overset** — så ustabilitet forringer tilliden til hele suiten, og det kan potentielt gøre den værre end ubrugelig.

Forståelsen af denne skade motiverer det at tage ustabilitet alvorligt.

At forstå de **almindelige årsager** — **timing-/async-problemer** (race conditions, ikke vente ordentligt på async-operationer, vilkårlige pauser — en topårsag især i UI/E2E-tests), **afhængighed af rækkefølge** (tests der afhænger af hinanden eller delt state), **eksterne afhængigheder** (rigtigt netværk/tjenester med deres udsving og nedetid), **ikke-determinisme** (tid, tilfældighed, tidszone, locale), og **miljøproblemer** (efterladt state, concurrency) — er nødvendigt for at diagnosticere ustabilitet.

At forstå, hvordan man **fikser og håndterer** dem — at fikse rodårsagerne (vente på vilkår i stedet for pauser, gøre tests uafhængige og rene, mockea eksterne afhængigheder, kontrollere tid og tilfældighed), sikre isolation, **ikke blindt genforsøge** (hvilket skjuler problemer), sætte vedvarende ustabile tests i karantæne, mens man fikser dem, og behandle ustabilitet som et alvorligt problem at spore og håndtere — afspejler den rigtige tilgang.

Da ustabile tests er et almindeligt, alvorligt problem, der undergraver tilliden til og værdien af en testsuite (et virkelig problem i mange virkelige projekter), og da forståelse af deres årsager og ordentlig håndtering (fikse rodårsager, isolation, ikke bare genforsøg) er nødvendig for at vedligeholde en pålidelig testsuite, er forståelse af ustabile tests værdifuld, praktisk vigtig viden — der løser et betydeligt problem fra den virkelige verden, vigtig for at holde en testsuite pålidelig og betroet, og afspejlende den praktiske modenhed til at håndtere et af testingens mest frustrerende og skadeligste problemer.