Não existe nada que destrua a confiança num pipeline mais rápido que um teste flaky: aquele que passa numa execução e falha na seguinte, sem nada ter mudado. Quando o time começa a clicar em "re-run" por reflexo, o CI virou decoração.

De onde vem a flakiness

• Tempo: sleep fixo em vez de espera por condição; corridas (race conditions).
• Estado compartilhado: testes que dependem da ordem ou de dados deixados por outro teste.
• Ambiente: rede, relógio, fuso horário, recursos concorrentes no CI.
• Aleatoriedade não controlada: dados randômicos sem seed.

Como combater

1. Espere por condição, não por tempo. Use auto-wait / web-first assertions em vez de sleep(3000).
2. Isole o estado. Cada teste cria e limpa seus próprios dados; nada de dependência de ordem.
3. Torne o tempo determinístico. Congele o relógio e fixe seeds de aleatoriedade.
4. Quarentena. Marque o teste flaky, tire-o do gate e abra um ticket — não deixe ele "treinar" o time a ignorar falhas.

# Detecte flakiness rodando o mesmo teste várias vezes
npx playwright test suspeito.spec.ts --repeat-each=20

Um teste flaky é pior que nenhum teste: ele custa tempo e, aos poucos, ensina o time a não confiar no verde.

Conclusão

Flakiness é dívida técnica de qualidade. Tratá-la com a mesma seriedade de um bug de produção é o que mantém o pipeline como uma fonte de verdade — e não como um obstáculo a ser contornado.

Nothing destroys trust in a pipeline faster than a flaky test: one that passes on one run and fails on the next, with nothing having changed. When the team starts clicking "re-run" by reflex, CI has become decoration.

Where flakiness comes from

• Timing: fixed sleep instead of waiting for a condition; race conditions.
• Shared state: tests that depend on order or on data left behind by another test.
• Environment: network, clock, time zone, competing resources in CI.
• Uncontrolled randomness: random data without a seed.

How to fight it

1. Wait for a condition, not for time. Use auto-wait / web-first assertions instead of sleep(3000).
2. Isolate state. Each test creates and cleans up its own data; no order dependencies.
3. Make time deterministic. Freeze the clock and fix randomness seeds.
4. Quarantine. Mark the flaky test, take it out of the gate and open a ticket — don't let it "train" the team to ignore failures.

# Detect flakiness by running the same test many times
npx playwright test suspeito.spec.ts --repeat-each=20

A flaky test is worse than no test: it costs time and, little by little, teaches the team not to trust green.

Conclusion

Flakiness is quality technical debt. Treating it with the same seriousness as a production bug is what keeps the pipeline a source of truth — and not an obstacle to be worked around.