Automated Generation of Issue-Reproducing Tests by Combining LLMs and Search-Based Testing

O artigo apresenta o BLAST, uma ferramenta que combina Modelos de Linguagem de Grande Escala (LLMs) e testes baseados em busca (SBST) para gerar automaticamente testes que reproduzem falhas a partir de pares de problemas e correções, demonstrando eficácia superior ao estado da arte em um benchmark e validando seu impacto prático através de um bot no GitHub.

O essencial

Imagine que você é um mecânico de carros. De repente, um cliente chega e diz: "Meu carro faz um barulho estranho quando acelero". Você conserta o problema (o "patch" ou correção). Mas, para ter certeza absoluta de que o conserto funcionou e que o problema não vai voltar amanhã, você precisa de um teste.

Esse teste seria algo como: "Pise no acelerador. Se o barulho sumiu, tudo certo. Se o barulho voltou, o conserto falhou."

O problema é que os programadores de software, muitas vezes, estão tão cansados ou com pressa que fazem o conserto, mas esquecem de escrever esse "teste de barulho". Sem o teste, ninguém sabe se o problema foi realmente resolvido ou se vai reaparecer no futuro.

É aqui que entra o BLAST, a ferramenta apresentada neste artigo.

O que é o BLAST?

O BLAST é como um assistente robótico superinteligente que tenta escrever esse "teste de barulho" automaticamente, assim que o programador faz o conserto.

Para fazer isso, o BLAST usa uma estratégia híbrida, misturando duas técnicas poderosas:

1. O "Cérebro" (LLM - Modelos de Linguagem): Imagine um estudante universitário muito inteligente que leu milhões de livros de programação. Ele entende a descrição do problema ("o barulho estranho") e a correção feita. Ele tenta escrever o teste baseado no que sabe.

   • O problema: Às vezes, esse estudante "alucina". Ele pode inventar peças que não existem no carro ou escrever instruções que não funcionam na prática.

2. O "Mecânico de Teste" (SBST - Teste Baseado em Busca): Imagine um mecânico experiente que não precisa ler livros, mas sim tentar e errar até acertar. Ele pega o carro, tenta mil combinações diferentes de aceleração, freio e direção, e anota o que acontece. Ele é lento, mas muito preciso e não inventa coisas que não existem.

   • O problema: Ele pode demorar muito e às vezes testa coisas que não têm nada a ver com o barulho específico que o cliente reclamou.

Como o BLAST funciona na prática?

O BLAST é como uma orquestra onde o "Cérebro" e o "Mecânico" trabalham juntos:

• Passo 1: O Mecânico começa. O robô usa o "Mecânico de Teste" para gerar testes básicos que funcionam no código corrigido. Ele cria uma "semente" (um esboço de teste).
• Passo 2: O Cérebro polpa. O "Cérebro" (o estudante inteligente) pega essa semente, olha para o problema original e para o código do carro, e escreve um teste muito mais refinado e inteligente, usando o que o Mecânico já descobriu.
• Passo 3: A Verificação. O robô roda o teste. Se o teste falha no código "quebrado" (antes do conserto) e passa no código "consertado", ele é um sucesso! O robô entrega esse teste para o programador.

O que eles descobriram?

Os pesquisadores testaram esse robô de duas formas:

1. No Laboratório (Benchmarks): Eles usaram um banco de dados de problemas antigos de software. O BLAST conseguiu criar o teste correto em 35,4% dos casos. Isso é muito melhor do que as ferramentas atuais, que conseguiam apenas cerca de 23,5%.

   • Analogia: Se você tem 100 carros com defeito, o BLAST consegue criar o teste de segurança para 35 deles, enquanto o concorrente só consegue para 23.

2. Na Vida Real (O Bot do GitHub): Eles criaram um "robô" que vive no GitHub (onde os programadores guardam seus códigos). Sempre que alguém abria um pedido de mudança (Pull Request) relacionado a um problema, o robô tentava criar o teste e sugeria nos comentários.

   • Eles observaram 32 casos reais. O robô sugeriu testes em 11 casos.
   • Os programadores humanos aceitaram e usaram 6 desses testes.
   • A lição: Às vezes, o robô cria um teste tecnicamente correto, mas o programador acha que não é necessário para aquele problema específico, ou o teste é muito "fictício" (usa muitos "mocks", que são como manequins de teste que não representam a realidade).

Por que isso é importante?

Antes, a gente confiava apenas no "Cérebro" (Inteligência Artificial pura) para escrever testes. Mas a IA às vezes inventa coisas. O BLAST mostra que, se você misturar a criatividade da IA com a precisão e a tentativa-e-erro do teste automatizado, você obtém resultados muito melhores.

É como ter um chef de cozinha (IA) que cria receitas incríveis, mas que às vezes usa ingredientes que não existem. O BLAST coloca um assistente de cozinha (SBST) ao lado dele para garantir que os ingredientes são reais e que a receita funciona de verdade antes de servir ao cliente.

Resumo da Ópera: O BLAST é uma ferramenta que ajuda a garantir que os bugs do software sejam realmente corrigidos, criando testes automáticos que combinam o melhor da inteligência artificial com a precisão da engenharia de software tradicional.

Resumo técnico

1. O Problema

Os testes de reprodução de problemas (issue-reproducing tests) são fundamentais para o desenvolvimento de software: eles falham no código com o bug e passam após a aplicação do patch, garantindo que o problema foi resolvido e não será reintroducido. No entanto, pesquisas indicam que desenvolvedores frequentemente cometem correções sem incluir esses testes, devido ao trabalho manual e demorado que sua criação exige.

Embora existam técnicas automatizadas baseadas em Modelos de Linguagem Grandes (LLMs) para gerar esses testes, elas apresentam limitações significativas:

• Alucinações: Os LLMs podem gerar testes que importam módulos inexistentes ou usam métodos que não existem.
• Falta de Contexto: Abordagens puramente baseadas em LLMs muitas vezes ignoram o contexto focal (estrutura da classe, mocks existentes) ou não aproveitam testes sintaticamente corretos gerados por outras ferramentas.
• Viés de Memorização: Avaliações baseadas apenas em dados históricos podem superestimar o desempenho devido à memorização dos modelos.

2. Metodologia: BLAST

O artigo propõe o BLAST (Bug-reproducing tests using LLMs and Search-Based Testing), uma ferramenta híbrida que combina LLMs e Teste de Software Baseado em Busca (SBST) para gerar testes que falham no código original e passam no código corrigido.

A arquitetura do BLAST consiste em dois componentes principais que trabalham em conjunto (ver Figura 3 do artigo):

A. Componente SBST (Baseado em Pynguin)

• Objetivo: Gerar testes que passam no módulo corrigido e identificar aqueles que falham no módulo original (testes Fail-to-Pass ou F→P).
• Desafio: O SBST tradicional (como o Pynguin) gera testes para maximizar a cobertura, mas não entende a semântica de um "bug" específico descrito em texto natural.
• Solução (Sementação/Seeding): O BLAST usa um LLM para gerar uma "semente" (um teste inicial) baseada na descrição do problema e no patch. Essa semente é analisada estaticamente e convertida para o formato canônico do Pynguin.
• Processo: O Pynguin executa mutações a partir dessa semente. Os testes gerados são executados no código original; se falharem, são candidatos a testes de reprodução.
• Filtragem: Testes que passam no código original são descartados. Testes que falham no original e passam no corrigido são mantidos.

B. Componente LLM

• Objetivo: Gerar um teste candidato diretamente, enriquecido com contexto.
• Contexto Recuperado: O BLAST não usa apenas a descrição do problema e o patch. Ele recupera e injeta no prompt do LLM:
  1. Contexto Focal: Assinaturas de classes/métodos alterados.
  2. Testes Existentes: Arquivos de teste mais acoplados às mudanças (identificados via histórico Git e acoplamento temporal).
  3. Testes Gerados pelo SBST: Testes sintaticamente corretos e que passam no código corrigido (gerados pelo Componente SBST) são usados como contexto para reduzir alucinações do LLM.
• Injeção: O LLM gera uma função de teste bruta, que é injetada no arquivo de teste apropriado do repositório.

3. Contribuições Principais

1. Técnica BLAST: Uma abordagem inovadora que orquestra LLMs e SBST, superando as limitações de uso exclusivo de LLMs.
2. Novo Benchmark (PyngBench): Criação e liberação de um conjunto de dados filtrado e compatível com ferramentas SBST para Python, derivado do TDD-Bench-Verified.
3. Validação de Métricas: Evidência empírica de que a métrica Fail-to-Pass (F→P) nem sempre corresponde a um teste de reprodução real de problemas (ex: testes que falham por importação ausente, não pelo bug em si).
4. Avaliação "In Vivo": Implementação de um bot no GitHub que atua em tempo real em repositórios de código aberto, coletando feedback real de desenvolvedores, algo raramente feito na literatura.

4. Resultados

A. Avaliação Baseada em Benchmark (TDD-Bench-Verified)

• Conjunto de Dados: 426 pares de problema-patch (após filtragem de casos triviais).
• Desempenho: O BLAST gerou testes de reprodução para 35,4% (151/426) dos casos.
• Comparação: Superou o estado da arte (AutoTDD, baseado apenas em LLMs) que alcançou 23,5%, e a abordagem zero-shot (20,2%).
• Custo: O BLAST utiliza 2 consultas ao LLM + 60 segundos de tempo de CPU para o SBST, sendo mais eficiente que workflows de 3 etapas puramente baseados em LLM.
• Contribuição do SBST: O componente SBST foi responsável por gerar testes únicos em 7,3% dos casos de sucesso (testes que o LLM não conseguiu gerar sozinho e que foram usados como contexto para o LLM em outros casos).

B. Avaliação "In Vivo" (Deploy no GitHub)

• Configuração: Bot implantado por 3 meses em 3 repositórios da Mozilla.
• Dados: 32 Pull Requests (PRs) acionados.
• Resultados: O BLAST gerou testes F→P em 11/32 casos (34,3%).
• Feedback dos Desenvolvedores:
  • Dos 11 testes propostos, 6 foram considerados válidos pelos mantenedores.
  • 2 foram integrados ao conjunto de testes do projeto.
  • Razões para rejeição: Alguns problemas não exigiam teste (ex: renomeação), o teste usava mocking excessivo ignorando funcionalidades críticas, ou o teste não reproduzia o problema central.
• Observação: O modelo llama3.3 performou melhor no cenário real (25% de sucesso) do que no benchmark histórico, sugerindo menor memorização, enquanto o gpt-4o teve desempenho superior no benchmark.

5. Significado e Conclusão

O trabalho demonstra que a combinação de LLMs (para compreensão semântica e geração de código) com SBST (para garantia de correção sintática e exploração sistemática) é superior ao uso isolado de LLMs para geração de testes de reprodução de bugs.

• Impacto Prático: O BLAST oferece uma ferramenta viável para auxiliar desenvolvedores, reduzindo a carga de trabalho manual na criação de testes de regressão.
• Lições Aprendidas: A avaliação com desenvolvedores revelou que a métrica puramente técnica (F→P) não é suficiente; a utilidade do teste depende do contexto do problema (se é um bug real ou uma nova feature) e da qualidade do mocking.
• Futuro: O estudo aponta a necessidade de ferramentas SBST que suportem melhor código complexo e gerem testes para métodos específicos (não apenas módulos inteiros) para aumentar a taxa de sucesso.

Em resumo, o BLAST avança o estado da arte ao provar que uma abordagem híbrida, validada tanto em benchmarks quanto em ambientes de produção reais, é o caminho mais promissor para a automação eficaz de testes de software.