O Que É um Teste Flaky?

Um teste flaky é aquele que passa e falha no mesmo código sem nenhuma mudança, produzindo resultados não confiáveis e não determinísticos.

Um teste flaky às vezes passa e às vezes falha, mesmo que nada no código tenha mudado. A flakiness é corrosiva: ela ensina os desenvolvedores a ignorar builds vermelhos, que é exatamente quando uma falha real escapa. Entender as causas comuns é o primeiro passo para eliminá-la.

O que torna um teste flaky

• Timing e condições de corrida entre operações assíncronas.
• Dependência da ordem de execução dos testes ou de estado compartilhado.
• Dependência do relógio real, de aleatoriedade ou da rede.
• Seletores instáveis ou sleeps fixos em testes de UI.

Por que a flakiness é tão prejudicial

Uma suíte flaky corrói a confiança no CI. Quando builds vermelhos às vezes não significam nada, as pessoas passam a reexecutar até ficar verde ou a ignorar falhas, e uma regressão genuína se esconde no ruído. O custo não é só o desperdício de reexecuções, mas a confiança perdida em toda a rede de segurança.

Um exemplo comum

Um teste que espera uma quantidade fixa de tempo em vez de esperar por uma condição vai passar em uma máquina rápida e falhar em uma lenta, um flake clássico de timing.

await sleep(100);        // flaky: hopes 100ms is enough
await waitFor(() => ready); // stable: waits for the condition

Corrigindo a flakiness na origem

A correção duradoura é remover o não determinismo: espere por condições em vez de usar sleep, isole o estado entre os testes, faça stub do relógio e da aleatoriedade, e nunca dependa da ordem dos testes. A reexecução automática pode mascarar um flake transitório, mas um teste que floqueia com frequência é um bug para corrigir, não para reexecutar para sempre.

Testes flaky e o CI

O CI é onde a flakiness mais dói, porque ela bloqueia merges e queima tempo de runner em reexecuções. A abordagem pragmática tem duas frentes: corrija os flakes determinísticos, e reexecute automaticamente as falhas genuinamente transitórias para que uma falha pontual de rede não derrube um bom build. A Latchkey reexecuta automaticamente flakes transitórios exatamente por essa razão, ao mesmo tempo em que ainda expõe testes persistentemente flaky para que você possa corrigi-los.

Principais conclusões

• Um teste flaky passa e falha no mesmo código, de forma não determinística.
• Ele corrói a confiança no CI e esconde regressões reais no ruído.
• Corrija flakes determinísticos na origem; reexecute automaticamente os transitórios reais.

Guias relacionados