How Far Are We from Detecting Flaky Tests? On the Limits of Code-Based Detection

Resumo Técnico: Sobre os Limites da Detecção de Testes Instáveis Baseada em Código

Definição do Problema
Testes instáveis (flaky tests) — testes que passam e falham na mesma versão de código — minam a integração contínua (CI) ao erodir a confiança nos resultados dos testes e desperdiçar o tempo dos desenvolvedores. Embora um corpo significativo de pesquisa proponha detectores estáticos baseados em código (usando padrões lexicais, métricas de código ou Grandes Modelos de Linguagem como o CodeBERT) para prever a instabilidade sem reexecução, a adoção industrial permanece limitada. Estudos recentes sugerem que o alto desempenho relatado (ex: pontuações F1 > 0,90) pode ser frágil, decorrente de falhas experimentais ou da premissa fundamental de que a instabilidade é uma propriedade estática do código do teste. Este artigo argumenta que o campo está estudando o problema errado: a instabilidade frequentemente surge de interações em tempo de execução com o ambiente de execução, o que significa que o código do teste sozinho frequentemente carece das informações necessárias para distinguir testes instáveis de não instáveis.

Metodologia
Os autores realizaram uma reprodução e reavaliação rigorosa de três detectores proeminentes baseados em código (Flakify, FlakyQ e FlakyXBert) usando um protocolo único e estrito. O estudo procede em três etapas:

1. Reprodução e Auditoria de Artefatos: Os autores reproduziram os três detectores usando seus pacotes de replicação oficiais. Eles auditaram os protocolos de avaliação e os conjuntos de dados para vazamento de dados (data leakage) e atalhos. Especificamente, eles abordaram o vazamento de dados em validação cruzada (onde os pesos do modelo não eram reinicializados entre as dobras/folds) e o atalho do "commit de correção" (fix-commit), onde os rótulos de não instabilidade foram derivados de versões corrigidas por desenvolvedores de testes instáveis, criando pares de código quase duplicados que os modelos poderiam explorar via similaridade superficial em vez de sinais de instabilidade.
2. Construção do C-IDoFT (Contrafactual Controlado): Para isolar o efeito dos atalhos de rotulagem, os autores criaram o C-IDoFT. Este conjunto de dados retém os testes instáveis confirmados por desenvolvedores do benchmark IDoFT original, mas reconstrói a classe não instável. Em vez de usar versões corrigidas de testes instáveis, os rótulos de não instabilidade foram derivados de 500 execuções repetidas dos módulos de teste. Este conjunto de dados serve como um controle para testar se os detectores baseados em código podem generalizar quando o atalho "fix-commit" é removido e os projetos são separados (avaliação de projeto-disjunto).
3. Construção do FlakeCI (Corpus Minerado de CI): Para investigar a origem dos sinais de instabilidade em sistemas complexos, os autores mineraram mais de 450.000 execuções de CI do GitHub Actions para construir o FlakeCI. Este conjunto de dados contém 86 testes de ponta a ponta (E2E) confirmados como instáveis que passaram e falharam no mesmo commit. Os autores analisaram manualmente o código do teste e os logs de CI para determinar se a causa raiz da instabilidade poderia ser atribuída apenas a esses artefatos.

Principais Resultados

• Reprodução e Vazamento de Dados: Quando o vazamento de dados foi corrigido (recarregando os modelos por dobra) e a avaliação de projeto-disjunto foi aplicada, o desempenho do Flakify e do FlakyQ colapsou. No benchmark IDoFT, a pontuação F1 ponderada caiu de ~0,95 para 0,80, igualando-se à linha de base da classe majoritária "sempre instável". No conjunto de dados FlakeFlagger, a pontuação F1 da classe instável caiu para 0,07, falhando em exceder a linha de base. O desempenho do FlakyXBert também caiu significativamente (de 0,94 para 0,83) após a correção de saídas de notebooks que inadvertidamente usavam dados de projetos diferentes.
• Avaliação C-IDoFT: No conjunto de dados controlado C-IDoFT, que remove o atalho do fix-commit e usa rótulos de não instabilidade confirmados por reexecução, ambas as reimplementações baseadas em CodeBERT (Flakify+ e FlakyLens+) não performaram melhor do que as linhas de base constantes em um cenário de projeto-disjunto. Suas pontuações F1 para a classe instável foram 0,035 e 0,070, respectivamente, comparadas a uma linha de base "sempre instável" de 0,054. No entanto, sob o protocolo original de validação cruzada aleatória (que permite a sobreposição de projetos), os mesmos modelos alcançaram pontuações altas (F1 > 0,68), confirmando que a aparente capacidade de detecção depende da similaridade dentro do projeto e de atalhos de rotulagem, não de sinais de instabilidade generalizáveis.
• Contraste FlakeBench: Os modelos performaram excepcionalmente bem no conjunto de dados curado FlakeBench (F1 > 0,96), sugerindo que o código do teste pode conter sinais separáveis para tipos específicos e curados de instabilidade (ex: aqueles reconhecíveis a partir de mensagens de correção). No entanto, esse sucesso não se transferiu para a instabilidade amplamente confirmada por desenvolvedores no C-IDoFT.
• Diagnóstico FlakeCI: Na análise de 86 testes E2E instáveis, os autores puderam atribuir uma causa a apenas 42% das falhas usando o código do teste e os logs de CI combinados. Para os 58% restantes, a causa raiz (frequentemente relacionada à instabilidade de rede, configuração de ambiente ou estado de tempo de execução) não pôde ser determinada sem evidências adicionais de execução.

Significância e Alegações
O artigo afirma que as altas pontuações F1 relatadas na literatura anterior são, em grande parte, artefatos da construção de benchmarks (especificamente o atalho do fix-commit) e dos protocolos de avaliação (vazamento de dados em validação cruzada e sobreposição de projetos), e não evidência da capacidade de um modelo de detectar instabilidade a partir do código.

Os autores argumentam que:

1. A instabilidade não é estática: Ela não é uma propriedade inerente ao código do teste, mas emerge de interações em tempo de execução. Perguntar "este teste é instável?" a partir apenas do código é um problema mal formulado para muitos tipos de instabilidade.
2. A detecção baseada em código atingiu um limite: Substituir o aprendizado de máquina tradicional por LLMs não supera a limitação de que o sinal para a instabilidade muitas vezes está ausente no código fonte.
3. Reenquadramento do problema: O campo deve mudar de prever se um teste é instável para classificar se uma falha observada é instável, baseando-se em evidências de execução (logs, stack traces, contexto de CI).

O artigo conclui que os detectores baseados em código são atualmente indistinguíveis das linhas de base de classe majoritária quando avaliados rigorosamente em instabilidades confirmadas por desenvolvedores com rótulos de não instabilidade confirmados por reexecução. O caminho a seguir reside em abordagens fundamentadas na execução, como classificação ao nível de falha e agentes que investigam ambientes de execução, em vez de análise estática de código.