O que são testes flaky e como você lida com eles?

Question

Accepted Answer

**Testes flaky** são testes que **passam ou falham inconsistentemente** sem mudanças no código — às vezes passando, às vezes falhando no mesmo código. Eles são um problema sério porque destroem a confiança na suíte de testes. Entender suas causas e soluções é importante.

## O que são testes flaky e por que são prejudiciais

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

## Causas comuns

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

## Corrigindo e gerenciando testes flaky

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

## Por que isso importa

Entender testes flaky e como lidar com eles é importante porque **testes flaky são um problema sério e comum que mina o valor de uma suíte de testes inteira**, portanto é um conhecimento prático valioso.

Um teste flaky (passando ou falhando inconsistentemente no mesmo código) é particularmente prejudicial porque **destrói a confiança**: quando testes falham de forma imprevisível, as pessoas começam a ignorar falhas ("é só flaky"), o que significa que **falhas reais também são perdidas** — então a flakiness degrada a confiança em toda a suíte, potencialmente tornando-a pior que inútil.

Entender esse dano motiva levar a flakiness a sério.

Entender as **causas comuns** — **problemas de timing/async** (race conditions, não aguardar adequadamente por operações assíncronas, sleeps arbitrários — uma causa primária especialmente em testes de UI/E2E), **dependência de ordem** (testes dependendo uns dos outros ou de estado compartilhado), **dependências externas** (rede real/serviços com seus problemas e tempo de inatividade), **não-determinismo** (tempo, aleatoriedade, timezone, locale), e **problemas de ambiente** (estado residual, concorrência) — é necessário para diagnosticar flakiness.

Entender como **corrigir e gerenciar** eles — corrigir causas raiz (aguardar condições em vez de sleeps, tornar testes independentes e limpos, mockar dependências externas, controlar tempo e aleatoriedade), garantir isolamento, **não fazer retry cego** (que esconde problemas), colocar em quarentena testes persistentemente flaky enquanto os corrige, e tratar flakiness como um problema sério a rastrear e resolver — reflete a abordagem correta.

Como testes flaky são um problema comum e sério que mina a confiança e o valor de uma suíte de testes (um problema real em muitos projetos do mundo real), e como entender suas causas e tratamento adequado (corrigir causas raiz, isolamento, não apenas retry) é necessário para manter uma suíte de testes confiável, entender testes flaky é conhecimento valioso e praticamente importante — abordando um problema real e significativo de testes, importante para manter uma suíte de testes confiável e confiança nela, e refletindo a maturidade prática para lidar com um dos problemas mais frustrantes e prejudiciais dos testes.