O Que É um Teste Flaky? Causas e Correções Explicadas
Um teste flaky é aquele que retorna resultados diferentes no mesmo código e nas mesmas entradas, passando em um run e falhando no seguinte sem motivo real.
Testes flaky são o tipo mais corrosivo de falha de CI porque não são reproduzíveis sob demanda. O código não mudou, o teste não mudou, e mesmo assim o resultado se inverte. Com o tempo, os desenvolvedores aprendem a ignorar builds vermelhos, e uma regressão real passa despercebida.
O que "flaky" realmente significa
Um teste é flaky quando seu resultado depende de algo diferente do comportamento que ele afirma verificar. Rode-o cem vezes e ele passa noventa e sete; as três falhas não estão lhe dizendo que o código está quebrado. A relação sinal-ruído da sua suíte de testes cai, e a confiança em cada resultado que ela produz também.
Causas comuns
- Timing e async: um teste faz uma asserção antes de uma operação terminar, então depende de quão rápida a máquina por acaso é.
- Estado compartilhado: testes vazam dados entre si, então a ordem ou o paralelismo muda o resultado.
- Dependências externas: uma chamada de rede real, um relógio ou uma seed aleatória introduz não determinismo.
- Pressão de recursos: um runner lento ou com pouca memória faz um teste que estaria fino sofrer timeout.
Testes flaky vs falhas transitórias de infraestrutura
Vale separar duas coisas que ambas parecem flakiness. Um teste flaky é um problema no próprio teste, corrigível apenas mudando o teste ou o código. Uma falha transitória de infraestrutura (um network blip, um timeout de registry, um out-of-memory kill no runner) é ambiental e corrigível com retry. Elas exigem respostas diferentes.
Como as equipes contêm a flakiness
A correção duradoura é tornar os testes determinísticos: remova I/O real, controle o tempo e a aleatoriedade e isole o estado. Até lá, as equipes colocam em quarentena testes sabidamente flaky para que não bloqueiem merges, e acompanham uma taxa de testes flaky para manter o problema visível em vez de ignorado.
O ângulo do Latchkey
Os runners gerenciados com autocorreção do Latchkey não conseguem corrigir para você um teste genuinamente flaky, mas eles removem o ruído ambiental que se disfarça de flakiness: quando um job falha por um problema transitório ou mecânico, como um network blip ou um out-of-memory kill, o runner o detecta e faz retry automaticamente, de modo que um blip pontual não faz seu build falhar. Isso deixa um conjunto menor e mais claro de falhas que são de fato bugs de teste.
Principais conclusões
- Um teste flaky passa e falha em código e entradas idênticos.
- As causas geralmente são timing, estado compartilhado, dependências externas ou pressão de recursos.
- Testes flaky (bugs de teste) diferem de falhas transitórias de infraestrutura (que são retryáveis).
- Torne os testes determinísticos; coloque o restante em quarentena e meça-o.