Testes Flaky no CI: Causas, Detecção e Contenção
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.
Principais conclusões
- Flaky = não determinístico; o resultado depende de algo diferente do código.
- Detecte pelo histórico por teste; um fail-then-pass no mesmo commit é o sinal.
- Contenha com quarentena + retries direcionados, e corrija a causa raiz.
- Nunca faça retry de tudo indiscriminadamente - isso esconde regressões reais.