Executando verificação de segurança...
1
Ofido
2 min de leitura ·

E se a IA pudesse ler seu relatório de coverage e escrever os testes que faltam? - Uma vontade de estudo e curiosidade que chegou a isso

Olá, comunidade do TabNews!

Recentemente, me peguei com uma curiosidade: "E se a IA pudesse ler meu coverage report e escrever os testes que faltam?". Movido por essa pergunta, pela vontade de estudar e cansado de procurar o prompt perfeito, alucinações e pr's rejeitados por causa de falta de testes ou coverage, decidi transformar isso em um projeto prático.

Mais do que criar uma ferramenta perfeita, meu objetivo era aprender. Eu queria entender como construir um projeto CLI (Command-Line Interface) do zero usando Typer, como manipular os dados de um arquivo .coverage com o Python e, claro, como integrar e interagir com APIs de IA (como a da OpenAI) - e usar IAs locais tambem - de formas diferentes.

Foi assim que nasceu o AIUnitTest.

O que (eu tentei) fazer?

A ideia do AIUnitTest é ser uma CLI em Python que:

  1. Lê o arquivo .coverage gerado após uma bateria de testes (ex: coverage run -m pytest).
  2. Identifica as funções e linhas que não foram testadas (além do padrão de testes usado no projeto como pytest ou unittest).
  3. Usa a API da OpenAI (e/ou LLM's locais) para analisar o código-fonte dessas funções e (tentar) gerar os testes unitários faltantes, adicionando-os aos (respectivos) arquivos de teste.

O Foco no Aprendizado

O verdadeiro valor desse projeto, para mim, foi a jornada de aprendizado:

  • Projetos CLI: Entender como o argparse (ou Typer/Click) funciona para criar comandos.
  • API do Coverage.py: Descobrir como ler e interpretar os dados brutos de cobertura de testes.
  • Integração com IA: Lidar com prompts, respostas e como injetar o código gerado de volta no arquivo de teste correto.
  • Lidar com LLM's: Lidar com diversas LLM's e apis, tanto localmente quanto via API.

⚠️ Disclaimer Importante: É um Experimento!

Quero deixar muito claro: este é um projeto altamente experimental e está longe de ser uma ferramenta robusta (mas funciona {as vezes kkkk}).

Sendo bem honesto, ele ainda não funciona muito bem e tem várias limitações. A IA nem sempre acerta, a lógica de inserção de código pode falhar, e ele definitivamente não vai resolver todos os seus problemas de cobertura de testes.

Estou publicando aqui não para "lançar um produto", mas para compartilhar o processo de estudo, a ideia e quem sabe mais alguns doidos dispostos a testarem e me ajudarem.

O projeto é open-source e adoraria opiniões, nada é escrito em pedra

O código está 100% aberto no GitHub. Se você também tem curiosidade sobre esse tipo de ferramenta, ou talvez já tenha tentado algo parecido, adoraria saber sua opinião.

  • Alguém já explorou a API do coverage?
  • Que outras abordagens vocês usariam para fazer a IA gerar testes mais assertivos?
  • Qualquer feedback sobre a estrutura do projeto é bem-vindo!

➡️ Link do Repositório: https://github.com/Ofido/AIUnitTest
tambem presente no PiPy: https://pypi.org/project/AIUnitTest/

Obrigado por lerem sobre minha pequena jornada de estudo!

Carregando publicação patrocinada...
1
Pilati

E se a IA pudesse ler meu coverage report e escrever os testes que faltam?

Bons testes não são os tstes de "caminho feliz" que certamente é o que a IA sabe fazer

Bons testes são escritos para prever cenários que não são óbvios, ter uma "cobertura de testes" mínima pode gerar uma falsa segurança de que a aplicação está segura.

Diversas vezes que eu estava escrevendo testes eu pensei "e se eu fizer dessa outra forma" e acabei encontrando bugs absurdos e que iriam passar caso não parasse justamente pra escrever esses testes chatos.

Se uma IA escrever os testes, nem que sejam os mais básicos, como vou ter esses momentos e pensar em cenários que normalmente um dev não pensa?

1
Ofido
  • Autor
    Autor

tenho até uma ISSUE aberta sobre isso, casos que a ia não consegue imaginar ou se ela deveria conseguir pensar em relação a proteção de camadas.
tive um bug sobre isso não faz muito tempo que um dos devs ultilizou a infra do banco que já estava pronta, mas ele não configurou as proteções de inserção na camada nova e acabou quebrando tudo e o teste unitário não conseguiria pensar isso nunca.

Dito isso, meu objetivo era realmente tentar cobrir o obvio primeiro, sei que o coverage não significa nada, mas em um projeto que, quanto mais pessoas usam, mas o obvio não é tão obvio assim e tambem possibilita um "change" de um trecho de código ou de uma infra inteira de uma maneira mais rapida e simples.