# Testes Flaky no CI: Causas, Detecção e Contenção

> O que torna os testes flaky, como detectar a instabilidade, e como contê-la com quarentenas e retries limitados sem esconder bugs reais.

Source: https://latchkey.dev/pt/learn/ci-cd-concepts/flaky-tests-in-ci  
Updated: 2026-06-25

Um teste flaky passa e falha no mesmo código. Deixada sem gestão, a instabilidade corrói a confiança no CI até que um build vermelho não signifique nada.

Testes flaky são não determinísticos: seu resultado depende de algo diferente do código sob teste. Eles são corrosivos porque treinam as equipes a ignorar falhas - o oposto do propósito do CI.

## Causas comuns

- Race conditions e suposições de timing (esperas baseadas em sleep).
- Dependência da ordem dos testes e estado mutável compartilhado.
- Dependência de redes reais, relógios ou serviços externos.
- Pressão de recursos (um runner lento e sobrecarregado estourando um timeout).

## Detectando a instabilidade

Acompanhe o histórico de pass/fail por teste ao longo das runs. Um teste que falha e depois passa no mesmo commit é flaky por definição. Rodar a suíte inteira repetidamente em um commit sabidamente bom expõe os piores ofensores.

## Contendo sem esconder bugs

Coloque em quarentena testes sabidamente flaky para que não bloqueiem merges, abra tickets para corrigir o não determinismo na raiz, e aplique retries limitados apenas a testes sabidamente flaky. O princípio: faça retry do ruído, nunca do sinal - uma falha que se reproduz consistentemente deve sempre aparecer.

## FAQ

### What is Flaky tests in CI?

Flaky tests are nondeterministic: their result depends on something other than the code under test. They are corrosive because they train teams to ignore failures - the opposite of what CI is for.

### Detecting flakiness?

Track per-test pass/fail history across runs. A test that fails and then passes on the same commit is flaky by definition. Re-running the whole suite repeatedly on a known-good commit surfaces the worst offenders.

### Containing it without hiding bugs?

Quarantine known-flaky tests so they do not block merges, file tickets to fix the root nondeterminism, and apply bounded retries only to tests known to be flaky. The principle: retry the noise, never the signal - a consistently reproducing failure must always surface.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt