LLMs conseguem encontrar testes flaky só pelo código? Estudo diz que não

Testes flaky são testes que às vezes falham e às vezes passam, sem motivo visível. Eles quebram o CI/CD, obrigam a refazer trabalho e minam a confiança nos testes automatizados. Os pesquisadores decidiram entregar o problema aos LLMs: será que uma rede neural consegue entender o código e apontar testes suspeitos? Os resultados decepcionaram.

Por que testes flaky são um inimigo tão incômodo

Um teste não confiável não é apenas um bug. Quando um teste falha em momentos aleatórios, os engenheiros deixam de confiar nele. Refazem o trabalho, reiniciam o pipeline e gastam horas depurando. Um bug clássico pode ser reproduzido; um teste flaky só se reproduz na segunda-feira às 3h43 da manhã. Isso destrói a velocidade de desenvolvimento.

As fontes de testes flaky são variadas e, muitas vezes, ocultas:

• Race conditions e problemas de timing
• Dependências do estado do banco de dados ou do sistema de arquivos
• Testes mal isolados que afetam uns aos outros
• Código assíncrono sem waits adequados
• Timeouts rígidos que não suportam a sobrecarga do servidor

Como os pesquisadores testaram os LLMs

A equipe pegou vários LLMs e fez uma pergunta simples: este é o código do teste, ele é flaky? Os modelos analisaram o código-fonte, tentaram reconhecer padrões (lógica de retry, sleep, isolamento fraco) e devolveram a probabilidade de haver um problema.

Em um dataset controlado, os resultados pareciam ótimos: os modelos alcançaram mais de 85% de acurácia. Precision e recall eram bons, e os gráficos lembravam os de qualquer projeto de ML bem-sucedido. O problema parecia resolvido.

Mas aí vem o paradoxo: quando os pesquisadores aplicaram os mesmos modelos a testes reais de outros projetos, o efeito quase desapareceu. A acurácia caiu e os falsos positivos aumentaram. O modelo claramente não entendeu a natureza do comportamento flaky.

Por que métricas não equivalem a compreensão

Essa é uma armadilha clássica do machine learning, que se esquece entre a leitura de artigos sobre novos modelos e o trabalho real. Um modelo pode aprender correlações do dataset, mas isso não significa que tenha entendido a causa. Por exemplo, se no dataset de treino todos os testes flaky continham Thread.sleep(), o modelo marcará como suspeito qualquer teste com essa função, mesmo que o sleep seja usado corretamente para sincronização.

Nos testes flaky, o problema é agudo: cada projeto tem seus próprios padrões de falha. O que quebra em uma arquitetura de microsserviços pode ser perfeitamente normal em uma aplicação de thread única. Os modelos foram treinados em um único recorte de dados e não enxergam o contexto do ambiente, as versões dos frameworks nem as particularidades da infraestrutura.

Boas métricas no conjunto de teste são condição necessária, mas não suficiente.

É preciso validação real com exemplos de produção.

O que isso significa

LLMs são uma ferramenta poderosa, mas não são mágica. Para problemas especializados, como a busca por testes flaky, é preciso ou mais contexto (histórico de falhas, metainformação sobre o ambiente, dados de carga) ou uma abordagem híbrida (LLM + análise estática + monitoramento de falhas em produção).

A moral é simples: não confie apenas em métricas. Tarefas específicas exigem uma abordagem específica.