Testes automatizados com IA: como não construir falsa segurança

Escrever teste é a tarefa que mais gente delega para IA, e faz todo sentido: é repetitivo, é chato e é a primeira coisa cortada quando o prazo aperta. A IA gera uma suíte inteira em um minuto, a cobertura salta para 90% e o painel fica verde.

O problema é que cobertura mede execução, não verificação. Uma linha "coberta" é uma linha que rodou durante o teste — não uma linha cujo comportamento foi conferido. Dá para ter 90% de cobertura e zero proteção, e é exatamente isso que acontece quando a suíte é gerada sem critério.

Os quatro testes inúteis que a IA mais produz

1. O teste que testa a linguagem

Você recebe algo que verifica se um objeto criado com certos valores tem esses valores. Não há lógica sendo exercitada — o teste confirma que a atribuição funciona. Ela funciona. Esse teste nunca vai falhar e nunca vai te avisar de nada.

2. O teste espelho da implementação

Este é o mais traiçoeiro. A IA lê o seu código e escreve o teste que confirma o que o código faz — inclusive o bug. Se a sua função calcula o desconto errado, o teste gerado espera o valor errado, passa, e agora o erro está congelado com aparência de comportamento aprovado.

Teste gerado a partir da implementação não verifica se o código está certo. Verifica se ele continua fazendo o que já fazia — inclusive o que faz de errado.

É a diferença fundamental entre teste e snapshot. Um teste de verdade nasce da especificação — do que deveria acontecer. Se a única fonte for o código, você não tem verificação, tem fotografia.

3. O teste que só exercita o caminho feliz

Ela testa a entrada válida com valor típico. Não testa lista vazia, número negativo, texto no lugar de número, campo nulo, valor no limite exato da regra, data no fim do mês. É justamente onde os bugs moram — e é o que não aparece se você não pedir explicitamente.

4. O teste de mock puro

Ela simula todas as dependências e depois verifica que os simulacros foram chamados. O teste passa sempre, porque não há nada real ali. Você testou que o seu código chama as funções que você mandou ele chamar — o que você já sabia lendo o código.

Como pedir teste que presta

Dê a especificação, não a implementação

É o ajuste mais importante de todos. Em vez de colar a função e pedir "escreve os testes", descreva o comportamento esperado e peça os testes a partir dele.

Ruim: "escreva testes para esta função de cálculo de frete" (com o código colado).

Bom: "Regra de frete: acima de R$ 200 é grátis. Até 5 kg, R$ 20. Acima de 5 kg, R$ 20 mais R$ 3 por quilo excedente. Região Norte tem acréscimo de 30%. Escreva os testes que verificam essa regra, incluindo os valores exatamente no limite."

No segundo caso, se a implementação estiver errada, o teste falha — que é justamente o que você quer que aconteça.

Peça os casos-limite pelo nome

Modelos não vão atrás do caso feio por conta própria. Liste as categorias que você quer cobertas: vazio, nulo, zero, negativo, valor máximo, tipo errado, coleção com um único item, coleção enorme, string com acento e caractere especial, e — em qualquer coisa com data — virada de mês, ano bissexto e fuso horário.

Um pedido que rende bem: "para cada parâmetro, liste os valores-limite que deveriam ser testados e por quê. Só depois escreva os testes." A lista costuma revelar caso que você mesmo não tinha considerado — e aí o valor apareceu antes do primeiro teste existir.

Exija um nome que descreva o comportamento

Nome de teste é documentação. testeCalculo1 não diz nada quando quebra no CI seis meses depois. freteGratisAcimaDeDuzentosReais diz exatamente qual regra foi violada, e quem lê o relatório de falha entende sem abrir o arquivo.

Uma asserção significativa por teste

Peça teste focado. Um teste que verifica oito coisas falha na primeira e esconde as outras sete — você conserta, roda de novo, falha na segunda. Testes pequenos apontam o problema direto.

A verificação que separa suíte real de suíte decorativa

Existe um método simples e definitivo, e vale mais que qualquer relatório de cobertura: quebre o código de propósito e veja se o teste acusa.

Inverta uma condição, troque um > por >=, mude um sinal, retorne um valor fixo. Rode a suíte. Se continuar verde, aqueles testes não protegem nada — e é melhor saber agora do que em produção.

Faça isso em três ou quatro pontos críticos logo depois de gerar uma suíte grande. Leva cinco minutos e é o único jeito honesto de saber se você ganhou proteção ou só ganhou número no painel. Existem ferramentas que automatizam essa ideia, mas o teste manual em quatro pontos já te dá 80% da resposta.

A inversão que funciona melhor: teste primeiro

Se você puder mudar a ordem, mude. Peça os testes antes da implementação: "escreva os testes que descrevem este comportamento. Vou revisar; depois você implementa para passar neles."

Isso resolve o problema estrutural pela raiz, porque o teste não pode espelhar uma implementação que ainda não existe. E tem uma vantagem prática grande: revisar teste é muito mais fácil que revisar implementação. O teste é curto, é legível e fala em termos de comportamento — você consegue julgar se está certo em segundos. Julgar se uma implementação está correta leva bem mais tempo e atenção.

Onde a IA é ótima em teste, sem ressalva

• Montar dados de teste realistas: gerar as vinte variações de entrada plausível é chato e ela faz rápido.
• Escrever o teste de regressão do bug que você acabou de achar. Aqui o comportamento esperado é conhecido e específico — condição ideal.
• Traduzir suíte entre frameworks. Trabalho mecânico e verificável.
• Explicar por que um teste está falhando, lendo a mensagem de erro junto com o código.
• Apontar o que não está coberto: "dada esta regra e estes testes, que cenário ficou de fora?" — excelente uso, e não gera nenhum teste ruim.

O resumo

A IA mudou o custo de escrever teste, não o de escrever bom teste. O trabalho difícil sempre foi decidir o que verificar — e isso continua sendo seu.

Dê a especificação em vez do código, peça os casos-limite pelo nome, exija nomes que descrevam comportamento e quebre o código de propósito para conferir se a suíte reage. Cobertura alta com teste que nunca falha é pior do que não ter teste: sem teste você sabe que está desprotegido; com teste falso, você acha que está seguro.