LLMs conseguem encontrar flaky tests pelo código? Estudo diz que não
O estudo avaliou se LLMs conseguem encontrar flaky tests — testes que falham sem motivo claro. O resultado foi decepcionante: boas métricas no dataset não signi
Testes flaky são testes que às vezes falham, às vezes passam, sem motivo aparente. Eles quebram CI/CD, forçam retrabalho e minam a confiança em testes automatizados. Pesquisadores decidiram confiar esse problema a LLMs: será que uma rede neural consegue entender o código e encontrar testes suspeitos? Os resultados foram decepcionantes.
Por que testes flaky são inimigos piores
Um teste não confiável não é apenas um bug. Quando um teste falha em momentos aleatórios, engenheiros deixam de confiar nele. Refazem o trabalho, reiniciam o pipeline, passam horas debugando. Um bug clássico pode ser reproduzido; um teste flaky só se reproduz numa segunda-feira às 3:43 da manhã. Isso mata a velocidade de desenvolvimento.
As fontes de testes flaky são diversas e frequentemente ocultas:
- Condições de corrida e problemas de timing
- Dependências do estado do banco de dados ou sistema de arquivos
- Testes mal isolados afetando uns aos outros
- Código assíncrono sem waits apropriados
- Timeouts rígidos que não toleram sobrecarga do servidor
Como pesquisadores testaram LLMs
Uma equipe pegou vários LLMs e fez uma pergunta simples: este código de teste é flaky? Os modelos analisaram o código-fonte, tentaram identificar padrões (lógica de retry, sleep, isolamento fraco) e produziram uma probabilidade de problema. Em um conjunto de dados controlado, os resultados foram excelentes: modelos alcançaram 85%+ de acurácia. Precisão e recall eram bons, gráficos pareciam típicos de projetos ML bem-sucedidos. Parecia que o problema estava resolvido.
Mas aqui está o paradoxo: quando pesquisadores aplicaram os mesmos modelos a testes reais de outros projetos, o efeito quase desapareceu. A acurácia caiu, falsos positivos aumentaram. O modelo claramente não entendeu a natureza do comportamento flaky.
Por que métricas não são iguais a compreensão
Esta é uma armadilha clássica de machine learning, esquecida entre ler artigos sobre novos modelos e trabalho real. Um modelo pode aprender correlações em um conjunto de dados, mas isso não significa que entendeu a causa. Por exemplo, se todos os testes flaky no conjunto de dados de treinamento continham `Thread.sleep()`, o modelo marcará qualquer teste com essa função como suspeito — mesmo que o sleep seja usado corretamente para sincronização.
Para testes flaky, o problema é agudo: cada projeto tem seus próprios padrões de violação. O que quebra em uma arquitetura de microsserviços pode ser completamente normal em uma aplicação single-threaded. Modelos foram treinados em um recorte de dados e não veem contexto ambiental, versões de frameworks ou especificidades da infraestrutura.
Boas métricas em um conjunto de testes são necessárias mas não suficientes.
Você precisa de validação real em exemplos em produção.
O que isso significa
LLMs são ferramentas poderosas, mas não são mágica. Para problemas especializados como encontrar testes flaky, você precisa de mais contexto (histórico de falhas, metadados ambientais, informações 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 requerem uma abordagem específica.