TestMap: Evidence Infrastructure for Foundation-Model-Assisted Test Generation

Resumo Técnico: TestMap – Infraestrutura de Evidências para Geração de Testes Assistida por Modelos de Fundação

Definição do Problema
Os modelos de fundação (FMs) são cada vez mais capazes de gerar testes unitários plausíveis; no entanto, determinar sua correção, utilidade, manutenibilidade e valor de integração continua sendo um desafio significativo. O problema central é uma questão de "validação recursiva": os testes gerados são tanto artefatos de código quanto artefatos de validação. Eles devem ser validados antes que possam ser confiáveis para validar o sistema sob teste. Atualmente, o processo de validação está fragmentado entre ferramentas díspares (sistemas de build, executores de testes, ferramentas de cobertura, ferramentas de mutação, analisadores estáticos), que frequentemente reportam apenas resultados agregados em vez de conectar a evidência a candidatos de teste individuais. Além disso, as abordagens existentes frequentemente descartam candidatos falhos ou intermediários, perdendo dados valiosos sobre limitações do modelo, falta de contexto ou potenciais defeitos no sistema sob teste.

Metodologia: A Infraestrutura TestMap
O artigo apresenta o TestMap, um protótipo de infraestrutura de código aberto projetado para automatizar a geração e avaliação de testes assistida por FM com base em evidências, visando especificamente repositórios C#/.NET. O TestMap trata os testes gerados como "candidatos" em vez de respostas finais, registrando seu ciclo de vida completo.

O sistema opera através de um pipeline estruturado:

1. Ingestão de Repositório e Análise Estática: O TestMap clona um repositório alvo, utiliza as APIs do Roslyn para analisar a solução e realiza análise estática para mapear o código-fonte, dependências e estruturas de teste. Ele coleta métricas de código e detecta test smells (usando uma versão customizada do xNose).
2. Execução de Baseline: Antes da geração, a suíte de testes existente é executada para estabelecer um baseline de cobertura, pontuações de mutação e resultados de execução.
3. Seleção de Alvo e Construção de Contexto: Os alvos de geração (ex: métodos de origem) são selecionados com base em critérios configuráveis, como linhas não cobertas, mutantes sobreviventes ou testes relacionados. Um "pacote de evidências" é construído, incluindo o código alvo, testes relacionados, lacunas de cobertura e convenções de framework.
4. Geração Guiada por Modelo: O TestMap emprega um pipeline de geração decomposto (inspirado no RUG) em vez de geração de prompt único. Ele divide a tarefa em etapas de planejamento (planejamento de cenário, nomenclatura de métodos, arranjo/setup, planejamento de entrada, planejamento de ação, planejamento de asserção) seguidas pela síntese final. Suporta diferentes modos de contexto (ex: NoHistory vs. ChainedHistory) e orçamentos de pass@k.
5. Validação e Reparo: Os candidatos gerados passam por validação pré-execução (extração de sintaxe, inserção, diagnósticos do compilador) e validação pós-execução (build, execução, cobertura, mutação). Candidatos que falham não são descartados; eles são preservados com dados de diagnóstico. Se habilitado, um loop de reparo utiliza erros do compilador, logs de execução e falhas de asserção para solicitar revisões ao modelo.
6. Persistência de Evidências: Todos os artefatos — incluindo prompts, respostas do modelo, logs de build, resultados de execução, deltas de cobertura e históricos de reparo — são persistidos em um banco de dados SQLite. Isso permite análise granular de candidatos individuais e comparações agregadas de estratégias.

Principais Contribuições
O artigo apresenta as seguintes contribuições:

1. Enquadramento do Problema: Define a geração de testes assistida por FM como um problema de validação recursiva, onde os testes gerados devem ser validados antes de servirem como evidência.
2. Protótipo TestMap: Introduz uma infraestrutura de evidências de código aberto que automatiza análise de repositório, validação de candidatos, coleta de evidências, rastreamento de reparo e registro de experimentos.
3. Preservação do Ciclo de Vida: O sistema preserva o ciclo de vida completo dos candidatos, incluindo resultados falhos, reparados, de baixo impacto e positivos em evidência, permitendo o estudo de resultados intermediários.
4. Experimentos Específicos de Repositório: Facilita experimentos que comparam modelos, prompts, estratégias de geração e fluxos de trabalho de reparo em bases de código concretas, indo além de benchmarks padronizados.
5. Modelo de Evidência: Define um modelo de evidência estruturado que vincula candidatos ao contexto do repositório, parâmetros de geração, resultados de execução e indicadores de qualidade.

Resultos e Descobertas
O artigo não apresenta um estudo empírico de larga escala com métricas de desempenho quantitativas (ex: "O TestMap melhorou a cobertura em X%"). Em vez disso, os "resultados" são a demonstração da capacidade da infraestrutura para:

• Ingerir e analisar com sucesso repositórios reais de C#/.NET.
• Executar o pipeline completo de geração-para-validação, incluindo o tratamento de falhas de build e erros de execução.
• Persistir históricos detalhados de candidatos, distinguindo entre resultados de ValidationFailed, Validated, ValidatedLowImpact e ValidatedEvidencePositive.
• Suportar comparações de estratégias de geração específicas de repositório (ex: prompting ingênuo vs. prompting baseado em métricas).

Os autores observam que a infraestrutura revela que os testes gerados frequentemente requerem reparo e que os candidatos falhos fornecem evidências críticas sobre a qualidade do oracle, lacunas de contexto e ineficiências do toolchain.

Significância e Alegações
O artigo alega que o TestMap aborda uma lacuna crítica de infraestrutura na engenharia de software. Sua significância reside em mudar o foco de meramente produzir testes executáveis para tornar os testes gerados observáveis, repetíveis e comparáveis.

• Além dos Benchmarks: O TestMap complementa benchmarks padronizados ao fornecer evidências de como a geração assistida por FM se comporta sob as restrições reais de um repositório específico (sistemas de build, dependências, estilos de teste existentes).
• Evidência para Tomada de Decisão: Ao preservar candidatos falhos e reparados, a ferramenta suporta a revisão por desenvolvedores e a análise empírica, ajudando a distinguir entre limitações do modelo, problemas de toolchain e defeitos reais do sistema.
• Direção Futura: Os autores concluem que o futuro da geração de testes assistida por FM exige infraestrutura que não apenas gere testes, mas que forneça a evidência necessária para decidir se esses testes são úteis, mantíveis e confiáveis. O TestMap é apresentado como um passo em direção a essa infraestrutura de evidências, reconhecendo desafios abertos como qualidade de asserção, flakiness, atribuição de métricas e aceitação pelo desenvolvedor.

O artigo mantém um tom modesto, declarando explicitamente que o protótipo atual não estuda diretamente as decisões dos desenvolvedores nem mede melhorias na calibração de confiança, mas sim fornece a infraestrutura de dados necessária para tais estudos futuros.