On the Flakiness of LLM-Generated Tests for Industrial and Open-Source Database Management Systems

Resumo Técnico: Sobre a Instabilidade de Testes Gerados por LLM para Sistemas de Gerenciamento de Banco de Dados Industriais e de Código Aberto

Definição do Problema
Testes instáveis (flaky tests), que produzem resultados inconsistentes quando executados múltiplas vezes no mesmo estado de código, são um desafio significativo no teste de software industrial, reduzindo a eficiência e erodindo a confiança dos desenvolvedores. Embora trabalhos recentes tenham identificado a instabilidade como um problema potencial em testes gerados por Grandes Modelos de Linguagem (LLMs), a prevalência, as causas raiz e os mecanismos de transferência de instabilidade neste contexto permanecem obscuros. Este estudo aborda a lacuna de pesquisa dedicada à instabilidade de testes gerados por LLMs, especificamente no contexto de Sistemas de Gerenciamento de Banco de Dados (DBMS), onde a confiabilidade dos testes é crítica para operações de negócios.

Metodologia
Os autores conduziram um estudo empírico envolvendo quatro DBMS: o sistema industrial de código fechado SAP HANA, e três sistemas de código aberto (MySQL, DuckDB e SQLite). O estudo focou em dois tipos de teste: testes unitários nativos em C++ e testes de sistema SQL.

• Abordagem de Geração de Testes: Os pesquisadores adotaram uma estratégia de amplificação de testes inspirada em Alshahwan et al. [5], solicitando aos LLMs a geração de versões estendidas de arquivos de teste existentes para cobrir casos de borda adicionais.
• Modelos: Dois LLMs foram avaliados: GPT-4o (selecionado por seu alto desempenho e capacidade de lidar com o código interno do SAP HANA) e Mistral-Large-Instruct-2407 (selecionado como uma alternativa de código aberto para reprodutibilidade). Ambos os modelos foram executados com uma temperatura zero para maximizar as taxas de sucesso de compilação.
• Ambiente de Execução: Para isolar a instabilidade causada pelo código gerado em vez de ruído ambiental, os testes foram executados 30 vezes cada dentro de contêineres Docker isolados. Os testes em C++ foram executados individualmente, enquanto os testes SQL foram executados em ordem de arquivo para respeitar o design dos respectivos frameworks de teste.
• Detecção de Instabilidade: Um teste foi classificado como instável se produzisse resultados tanto de passagem quanto de falha ao longo das 30 execuções.
• Experimento de Transferência de Instabilidade: Para avaliar a suscetibilidade à "transferência de instabilidade", os autores injetaram uma asserção não determinística (falhando com 50% de probabilidade) em arquivos de teste existentes antes de solicitar aos LLMs a geração de novos testes.

Principais Contribuições

1. Análise de Prevalência: Uma avaliação quantitativa da proporção de testes instáveis em código gerado por LLM comparado aos testes existentes escritos por humanos em quatro DBMS.
2. Identificação de Causa Raiz: Uma inspeção manual e categorização das causas raiz da instabilidade em testes gerados por LLM, distinguindo entre problemas decorrentes do processo de geração e aqueles transferidos do contexto.
3. Benchmark de Transferência de Instabilidade: Uma avaliação experimental do grau em que os LLMs transferem padrões de instabilidade de exemplos fornecidos no contexto para o código recém-gerado, comparando o desempenho entre contextos de código fechado (SAP HANA) e código aberto (MySQL).

Resultados

• Compilação e Taxas de Sucesso: Os LLMs tiveram dificuldades significativas em gerar código C++ compilável para o projeto de código fechado SAP HANA (Taxa de Sucesso de Compilação de ~40-46%), atribuídas à falta de dados de treinamento do modelo sobre o código base específico. Em contraste, a geração de testes SQL mostrou altas taxas de aprovação (81-95%).
• Prevalência de Instabilidade: A proporção de testes instáveis no código gerado por LLM foi geralmente um pouco superior aos testes existentes.
  • Para testes C++, o GPT-4o gerou 0,29% de testes instáveis para o SAP HANA e 0,18% para o MySQL, enquanto o Mistral gerou taxas ligeiramente superiores (0,39% e 0,71%, respectivamente).
  • Para testes SQL, onde nenhum teste instável existente foi encontrado nas suítes originais, os LLMs geraram 96 testes instáveis no total (43 pelo GPT-4o, 53 pelo Mistral).
• Causas Raiz: A causa raiz mais prevalente de instabilidade em testes gerados por LLM foi "Coleção Não Ordenada" (63% de 115 testes instáveis). Isso ocorreu quando os LLMs geraram consultas SQL assumindo uma ordem específica de resultados sem usar ORDER BY, levando a falhas intermitentes.
  • A instabilidade por NIO (Resultado Não Idempotente) foi a segunda causa mais comum (10%), frequentemente resultante de o LLM mimetizar testes existentes que poluíram o ambiente de execução.
  • Problemas de concorrência foram observados principalmente em testes gerados pelo Mistral.
• Transferência de Instabilidade: Ambos os LLMs demonstraram suscetibilidade à transferência de instabilidade injetada do contexto do prompt para os testes gerados.
  • No contexto do SAP HANA (código fechado, sem dados de treinamento), a taxa de transferência foi maior (~69-78% dos testes gerados continham a asserção instável injetada).
  • No contexto do MySQL (código aberto, provavelmente presente nos dados de treinamento), a taxa de transferência foi menor (~41-58%).
  • Isso sugere que os LLMs dependem mais fortemente do contexto fornecido quando carecem de conhecimento prévio do sistema, podendo adotar correlações espúrias (como asserções instáveis) como padrões de codificação válidos.

Significância e Alegações
O artigo afirma fornecer os primeiros insights dedicados sobre a instabilidade de testes gerados por LLM para sistemas de banco de dados. Os autores concluem que, embora os LLMs possam gerar código de teste com aparência natural, eles introduzem riscos específicos de instabilidade, particularmente em relação a estruturas de dados não ordenadas e à transferência de defeitos existentes.

O estudo destaca que a transferência de instabilidade é um problema crítico, especialmente em ambientes de código fechado onde os modelos carecem de dados de treinamento e dependem fortemente de aprendizado em contexto. Consequentemente, os autores aconselham os profissionais a priorizar a correção de testes instáveis existentes antes de aplicar abordagens de geração baseadas em LLM para evitar a propagação de instabilidade. Eles também enfatizam a necessidade de fornecer contexto personalizado aos LLMs para mitigar causas raiz como suposições de "coleção não ordenada", observando que as janelas de contexto atuais podem ser insuficientes para sistemas grandes como o SAP HANA. As descobertas servem como uma base cautelar para desenvolvedores e pesquisadores que visam integrar LLMs em pipelines de testes automatizados.