Large-scale, Independent and Comprehensive study of the power of LLMs for test case generation

Este estudo apresenta a primeira avaliação empírica em larga escala da geração de testes unitários por modelos de linguagem (LLMs), demonstrando que, embora técnicas de raciocínio como GToT melhorem a confiabilidade e a legibilidade em comparação com métodos baseados em busca, as altas taxas de falhas de compilação e defeitos de manutenção exigem abordagens híbridas para resultados prontos para produção.

O essencial

Imagine que você é o chefe de uma grande fábrica de software. O trabalho de criar "testes" (que são como exames de saúde para o código) é essencial para garantir que o produto final não tenha defeitos. Mas criar esses testes manualmente é chato, demorado e os programadores muitas vezes pulam essa etapa.

Para ajudar, existem duas ferramentas principais:

1. O "Robô Tradicional" (EvoSuite): Ele é como um inspetor de segurança muito rigoroso e rápido. Ele corre de um lado para o outro, verificando cada parafuso e linha de código para garantir que nada foi esquecido. O problema? Ele é um pouco "burro" em termos de linguagem. Os testes que ele cria funcionam, mas são difíceis de ler, parecem escritos por um robô sem alma e são confusos para humanos.
2. O "Novo Estagiário Inteligente" (LLMs - Modelos de Linguagem): São como estagiários superinteligentes que leram todos os livros do mundo. Eles escrevem testes que parecem feitos por humanos: nomes bonitos, frases claras e fáceis de entender. Mas, como qualquer estagiário novo, eles às vezes alucinam: inventam ferramentas que não existem ou esquecem de trazer o equipamento certo.

O que este estudo fez?
Os autores pegaram quatro desses "estagiários inteligentes" (GPT-3.5, GPT-4, Mistral e Mixtral) e os colocaram para trabalhar em uma fábrica gigante com mais de 200.000 tarefas. Eles queriam ver se, ao dar instruções melhores (o que chamam de Prompt Engineering), o estagiário poderia fazer um trabalho tão bom quanto o robô tradicional, mas com a beleza de um humano.

Eles testaram cinco maneiras de dar ordens:

• Sem ajuda (Zero-Shot): "Aqui está o código, faça um teste."
• Com exemplos (Few-Shot): "Aqui está um exemplo de como fazer, agora faça outro."
• Pensando passo a passo (Chain-of-Thought): "Primeiro pense no que pode dar errado, depois escreva o teste."
• Explorando caminhos (Tree-of-Thought): "Vamos imaginar três especialistas discutindo qual é a melhor forma de testar."
• O Guia Mestre (GToT): Uma versão aprimorada onde três especialistas simulados colaboram e corrigem uns aos outros antes de entregar o trabalho.

O que eles descobriram? (As Descobertas Principais)

1. O Estagiário é Ótimo em Escrever, Ruim em Não Inventar Coisas:
   O "Novo Estagiário" escreve testes que são muito mais fáceis de ler e entender do que os do "Robô Tradicional". É como comparar um bilhete manuscrito com carinho (LLM) com uma lista de verificação em código binário (EvoSuite).
   Porém, o estagiário comete um erro grave: ele alucina. Ele inventa funções que não existem ou usa bibliotecas que o computador não tem. Isso faz com que, em muitos casos, o teste nem sequer consiga ser executado (falha na compilação). O Robô Tradicional, por outro lado, quase nunca falha em compilar, mas o resultado é feio.

2. A Forma de Dar a Ordem Importa Muito:
   Dar apenas uma ordem simples não é suficiente. Quando os pesquisadores usaram a técnica do "Guia Mestre" (GToT), onde o modelo é forçado a "pensar" e "discutir" antes de escrever, a qualidade melhorou muito. Os testes ficaram mais organizados e menos propensos a erros de estrutura. Mas, mesmo com essa ajuda, o estagiário ainda inventa coisas que não existem.

3. O Robô Tradicional ainda é o Rei da Cobertura:
   Se o objetivo é garantir que cada linha de código foi testada, o "Robô Tradicional" (EvoSuite) ainda ganha de longe. Ele explora o código de forma sistemática. O estagiário inteligente tende a pular partes complexas ou a não entender como conectar peças diferentes do sistema. O estagiário cobre cerca de 50-70% do que o robô cobre.

4. O Problema dos "Odores" (Test Smells):
   Na programação, um "cheiro" ruim é um sinal de que o código está mal feito (como usar números mágicos sem explicação ou fazer muitas verificações confusas).

   • O Robô Tradicional cria testes com muitos "cheiros" de repetição e lógica confusa.
   • O Estagiário escreve códigos mais limpos, mas ainda comete erros clássicos, como usar números sem contexto (ex: if (x == 15) em vez de if (x == MAX_TEMPERATURE)).

A Conclusão Final (A Lição do Dia)

Não espere que o "Estagiário Inteligente" substitua o "Robô Tradicional" ou o programador humano totalmente ainda.

• O Robô Tradicional é ótimo para garantir que nada foi esquecido (cobertura), mas o resultado é difícil de manter.
• O Estagiário (LLM) é ótimo para criar a "espinha dorsal" do teste, algo que um humano consegue ler e entender rapidamente.

A Solução Ideal?
Um trabalho híbrido. Use o "Estagiário" para escrever o rascunho inicial do teste (que será bonito e legível) e use o "Robô Tradicional" ou ferramentas de verificação para garantir que tudo compile, que não haja alucinações e que a cobertura seja completa.

Em resumo: A Inteligência Artificial é uma ferramenta incrível para ajudar a escrever testes melhores e mais humanos, mas ela ainda precisa de supervisão humana e de ferramentas tradicionais para garantir que o software realmente funcione sem bugs. Não é hora de demitir o inspetor de segurança, mas é hora de dar a ele um assistente muito mais carismático.

Resumo técnico

Aqui está um resumo técnico detalhado do artigo "Prompt Engineering in LLMs for Automated Unit Test Generation: A Large-Scale Study", apresentado em português:

1. Problema e Motivação

A geração de testes unitários é fundamental para a confiabilidade do software, mas a criação manual é demorada e frequentemente negligenciada. Abordagens tradicionais baseadas em busca (SBST), como o EvoSuite, otimizam a cobertura de código, mas frequentemente produzem testes com baixa legibilidade, nomes não intuitivos e oráculos genéricos, dificultando a manutenção.

Embora os Grandes Modelos de Linguagem (LLMs) mostrem promessa na geração de testes com melhor legibilidade e convenções de nomenclatura mais naturais, existem lacunas críticas na pesquisa atual:

• Falta de avaliação abrangente em cenários de nível de classe (focando em dependências entre métodos).
• Insuficiência na análise de estratégias de prompting baseadas em raciocínio (além do Zero-Shot básico).
• Desconhecimento sobre a viabilidade de extração, compilação e a presença de "cheiros de teste" (test smells) em larga escala.
• Risco de vazamento de dados de treinamento, onde modelos podem estar memorizando testes existentes em benchmarks populares.

2. Metodologia

O estudo realiza uma avaliação empírica em larga escala, gerando 216.300 casos de teste direcionados a 690 classes Java em três conjuntos de dados distintos:

1. Defects4J: Software real com bugs conhecidos (foco em cenários de correção).
2. SF110: Projetos Java acadêmicos e industriais existentes.
3. CMD (Custom Mini Dataset): Projetos curados lançados após Maio de 2023 para mitigar vazamento de dados de treinamento do LLM.

Configuração Experimental:

• Modelos de LLM: Quatro modelos de última geração (GPT-3.5-turbo, GPT-4, Mistral 7B e Mixtral 8x7B).
• Técnicas de Prompting: Cinco estratégias comparadas:
  • Zero-Shot Learning (ZSL)
  • Few-Shot Learning (FSL)
  • Chain-of-Thought (CoT)
  • Tree-of-Thought (ToT)
  • Guided Tree-of-Thought (GToT): Uma abordagem nova proposta pelos autores que simula colaboração entre três "testadores" para refinar iterativamente os testes.
• Baseline: O EvoSuite foi utilizado como a referência padrão da indústria para geração de testes baseada em busca (SBST).
• Métricas de Avaliação:
  • Extração e Formato: Match Success Rate (MSR) e Code Extraction Success Rate (CSR) para medir a capacidade de extrair código válido do texto natural do LLM.
  • Correção Técnica: Sintaxe, compilação (taxa de sucesso) e análise de erros de compilação (alucinações de símbolos, pacotes inexistentes).
  • Qualidade Humana: Legibilidade (usando o modelo de Scalabrino et al.), complexidade (ciclomática e cognitiva) e detecção de test smells (usando TsDetect).
  • Cobertura: Cobertura de linhas, instruções e métodos (via JaCoCo).

3. Principais Contribuições

1. Investigação Sistemática de Engenharia de Prompt: Demonstra que estratégias de raciocínio estruturado (especialmente GToT) superam significativamente o Zero-Shot e o Few-Shot na melhoria da estrutura, compilação e aderência a instruções.
2. Análise de Correção Estrutural e Extração: Introduz a aplicação de MSR e CSR para testes unitários, revelando que a extração limpa de código é um gargalo crítico antes mesmo da compilação.
3. Diferenciação entre Legibilidade e Manutenibilidade: Mostra que, embora os testes gerados por LLMs sejam mais legíveis que os do EvoSuite, eles ainda sofrem de problemas de design recorrentes (como "Magic Number Tests" e "Assertion Roulette") que prejudicam a manutenção a longo prazo.
4. Avaliação Multi-Dataset e Multi-Modelo: Fornece uma visão abrangente sobre como diferentes modelos e conjuntos de dados afetam a geração, incluindo um dataset (CMD) projetado especificamente para evitar vazamento de dados de treinamento.
5. Repositório Público: Disponibilização de um benchmark completo com prompts, scripts de avaliação e resultados para reprodução.

4. Resultados Chave

• Capacidade de Geração (RQ0): Os LLMs têm uma taxa de geração bruta alta (>90% na maioria dos casos), superando o EvoSuite em consistência de saída (o EvoSuite falhou em gerar testes para algumas classes do Defects4J).
• Impacto do Prompting (RQ1): O GToT foi a estratégia mais eficaz para garantir que o código fosse extraído corretamente (MSR e CSR mais altos). O Few-Shot (FSL) frequentemente performou pior do que o Zero-Shot em termos de aderência estrutural.
• Correção e Compilabilidade (RQ2):
  • Embora ~90% do código extraído seja sintaticamente correto, a taxa de compilação é baixa (<10%) para LLMs.
  • O principal obstáculo são alucinações: referências a símbolos inexistentes (86% dos erros em GPT-3.5) e pacotes que não existem.
  • O EvoSuite mantém uma taxa de compilação muito superior (98-100%), embora também tenha falhas ocasionais.
  • O GToT e o CoT reduzem erros de acesso privado e melhoram a estrutura, mas não resolvem completamente o problema de dependências.
• Legibilidade e Manutenibilidade (RQ3 & RQ4):
  • Os testes gerados por LLMs são significativamente mais legíveis (21-40% de melhoria) do que os do EvoSuite, com nomes de variáveis mais claros e estrutura mais humana.
  • O GToT e o CoT produzem os testes mais legíveis.
  • No entanto, a legibilidade não garante a ausência de defeitos: testes com GToT apresentaram mais "bugs estruturais" sutis (detectados pelo SpotBugs) do que o Zero-Shot.
• Cobertura de Código (RQ5):
  • O EvoSuite supera consistentemente todos os LLMs em cobertura de linhas, instruções e métodos (atingindo ~94-100% de cobertura mediana).
  • Os LLMs mostram alta variabilidade: desempenho moderado no Defects4J (possivelmente devido a vazamento de dados) e muito baixo no SF110 (devido à complexidade estrutural).
  • O Prompting baseado em raciocínio melhora a cobertura dos LLMs, mas não fecha a lacuna com a busca sistemática do EvoSuite.
• Cheiros de Teste (RQ6):
  • Magic Number Tests são onipresentes em todos os modelos e prompts (85-100%).
  • Assertion Roulette é reduzido drasticamente pelo GToT e CoT (caindo para ~6% em alguns casos, contra ~50% no EvoSuite).
  • O EvoSuite exibe altos níveis de "Lazy Test" e "Exception Handling" smells, refletindo sua otimização puramente para cobertura.

5. Significado e Conclusão

O estudo conclui que os LLMs são ferramentas assistivas eficazes para gerar esqueletos de testes legíveis e mantíveis, superando as abordagens tradicionais (SBST) em qualidade humana e clareza. No entanto, eles ainda não são substitutos autônomos para ferramentas de teste robustas devido a:

1. Baixa taxa de compilação direta (devido a alucinações de dependências).
2. Cobertura de código inferior à das técnicas baseadas em busca.
3. Persistência de cheiros de teste que afetam a manutenibilidade a longo prazo.

Recomendação Principal: A abordagem ideal é híbrida. Deve-se combinar a geração baseada em LLM (para legibilidade e estrutura) com validação automatizada, resolução de dependências e refinamento baseado em busca (SBST) para garantir robustez, compilação e cobertura adequada. O Prompt Engineering (especialmente GToT) é crucial para maximizar a qualidade, mas não elimina a necessidade de supervisão humana e validação rigorosa.