Testes automatizados gerados por IA: como validar e confiar

Testes automatizados gerados por IA: como validar e confiar

Para confiar em testes automatizados gerados por IA, não basta vê-los passar: é preciso provar que eles falham quando o código está errado. As técnicas mais úteis são o teste de mutação, a falha proposital (quebrar o código de propósito e observar se algum teste reclama) e a leitura da cobertura pelo que é verificado, não pelas linhas executadas. Um teste que só confirma o que o código já faz dá sensação de segurança sem proteger nada.

Principais pontos

• Teste que passa não prova nada. O que prova é um teste que falha quando o comportamento está errado.
• Quando a IA escreve o teste olhando o código, ela tende a descrever o que o código faz, não o que ele deveria fazer.
• Teste de mutação e falha proposital são as duas formas mais diretas de medir se o teste detecta defeitos reais.
• Cobertura de linhas mostra o que foi executado, não o que foi verificado. Olhe asserções, bordas e regras de negócio.
• Peça os testes a partir da especificação, revise por amostragem e trate o lote como um piloto com critério de decisão.

Por que testes gerados por IA enganam com tanta facilidade

Um modelo de linguagem recebe uma função e produz testes que compilam, rodam e passam. Isso é exatamente o problema: passar é o caminho de menor resistência. Se o teste foi derivado do código, o valor esperado muitas vezes é copiado do resultado que o próprio código devolve. Se o código tem um erro, o teste herda o erro e o carimba como correto.

Há padrões que aparecem com frequência em testes gerados sem cuidado:

• Asserções fracas, como verificar apenas que o resultado não é nulo ou que nenhuma exceção foi lançada.
• Testes que reimplementam a lógica da função dentro do próprio teste, repetindo o mesmo cálculo.
• Uso excessivo de mocks, a ponto de o teste verificar apenas que o mock foi chamado.
• Casos felizes em abundância e quase nenhum caso de borda, entrada inválida ou erro de integração.
• Nomes bonitos que prometem uma regra de negócio que a asserção não confere.

Nada disso é exclusivo de IA, pessoas também escrevem assim. A diferença é o volume: a IA gera dezenas de testes em minutos, e a revisão humana tende a relaxar diante de tanta aparência de qualidade.

Um teste só vale o que a falha dele consegue denunciar.

Como o teste de mutação mostra se os testes pegam defeitos

O teste de mutação inverte a pergunta. Em vez de perguntar se os testes passam no código atual, ele altera o código de forma automática, criando pequenas variações chamadas mutantes: troca um sinal de maior por maior ou igual, inverte uma condição, remove uma chamada, muda uma constante. Depois roda a suíte contra cada mutante. Se algum teste falha, o mutante foi morto. Se todos passam, o mutante sobreviveu, e isso significa que aquele comportamento não está protegido.

Existem ferramentas maduras para as linguagens mais comuns nas equipes brasileiras: Stryker para JavaScript e TypeScript, PIT para Java, mutmut para Python e Infection para PHP, entre outras. Os detalhes de instalação, operadores de mutação e opções de configuração estão na documentação oficial de cada uma, e vale consultá-la antes de definir qualquer regra interna.

Como usar o resultado na prática:

• Rode a mutação primeiro no módulo mais crítico, não no repositório inteiro. É uma técnica mais lenta que a suíte comum.
• Liste os mutantes sobreviventes e leia um por um. Alguns são equivalentes (a mudança não altera o comportamento) e podem ser ignorados.
• Para cada sobrevivente relevante, escreva ou peça um teste que o mate, descrevendo na especificação qual regra ele protege.
• Guarde o relatório junto da revisão, para que a decisão de aceitar o lote tenha evidência.

A mutação não substitui o julgamento. Ela aponta onde os testes são frouxos, mas não diz se a regra de negócio testada está certa. Para isso, você precisa da especificação.

Falha proposital: o método manual que qualquer equipe pode usar hoje

Se a ferramenta de mutação ainda não está no pipeline, a falha proposital faz o mesmo raciocínio à mão. A pessoa que revisa escolhe um trecho importante do código, introduz um defeito realista e roda os testes. Se tudo continua verde, o teste não protege aquele trecho.

Defeitos propositais que costumam revelar fraquezas:

• Trocar uma comparação de limite (maior para maior ou igual) em uma regra de aprovação ou de desconto.
• Inverter uma condição de permissão, por exemplo quem pode cancelar um pedido.
• Remover a validação de um campo obrigatório.
• Retornar o valor sem arredondar, ou arredondar na direção errada.
• Ignorar um erro vindo de uma integração externa e seguir como se tivesse dado certo.

Para o time, vale combinar uma regra simples: nenhum lote de testes gerados por IA entra sem que a pessoa revisora tenha quebrado de propósito pelo menos alguns pontos de maior risco e visto os testes falharem. É barato, dispensa ferramenta e ensina a equipe a ler testes com desconfiança saudável.

Outra variação útil é o caminho inverso: peça à IA que escreva os testes sem ver a implementação, apenas a especificação, e só depois rode contra o código. Quando um teste falha, há duas hipóteses: o código está errado ou a especificação estava ambígua. As duas descobertas têm valor.

Cobertura útil: o que medir além de linhas executadas

Cobertura de linhas indica que o código foi executado durante os testes. Não indica que alguém conferiu o resultado. Um teste sem asserção pode dar cobertura alta e proteção nula. Por isso, ao avaliar testes gerados por IA, troque a pergunta de quanto foi coberto para o que foi verificado.

Um guia de decisão em forma de lista, para cada teste do lote:

• Existe uma asserção sobre o resultado de negócio (valor, estado, mensagem), e não só sobre ausência de erro? Se não, rejeite ou reescreva.
• O valor esperado vem da especificação ou foi copiado da saída do código? Se foi copiado, confirme com alguém que conhece a regra.
• Há casos de borda: vazio, zero, valor no limite, texto com acento, data de virada de mês? Se não, peça.
• Há pelo menos um caso de entrada inválida ou de falha de dependência? Se não, o teste só cobre o caminho feliz.
• O mock substitui apenas o que é externo, ou esconde a lógica que deveria ser testada? Se esconde, simplifique.
• O teste falharia se a regra fosse alterada? Responda com falha proposital ou mutação, não com opinião.

Cobertura continua sendo um sinal, mas como piso, não como meta. Quando a meta é um número, a IA e as pessoas aprendem a atingi-lo com testes fracos.

Cenário ilustrativo: a regra de desconto que passou em tudo

Cenário ilustrativo: uma empresa de distribuição tem uma função que calcula desconto em pedidos. A regra escrita pelo comercial diz que o desconto vale para pedidos a partir de determinado valor. O desenvolvedor pede à IA que gere testes olhando o código existente, e o código, por descuido, aplica o desconto apenas para pedidos acima do valor, deixando de fora o pedido exatamente no valor limite.

A IA gera vários testes: um pedido pequeno sem desconto, um pedido grande com desconto, um pedido com cliente sem cadastro. Todos passam. A cobertura da função fica alta. Ninguém testou o pedido exatamente no limite, e, se testasse olhando o código, o valor esperado seria copiado do comportamento errado.

Na revisão, a pessoa troca o sinal de comparação como falha proposital e roda a suíte. Tudo continua verde. Esse é o sinal: a fronteira não está protegida. Ao pedir um teste novo a partir do texto da regra comercial, o teste de borda falha contra o código atual, e o defeito real aparece antes de chegar a um cliente.

O exemplo é inventado para ilustrar o mecanismo, mas o padrão é comum: o erro mora na fronteira, e é na fronteira que testes gerados do código costumam ser omissos.

Passo a passo para validar um lote de testes gerados por IA

Um roteiro enxuto que pode ser adotado em qualquer repositório, em ordem:

• Primeiro, escreva ou reúna a especificação do comportamento: regras de negócio, limites, erros esperados. Pode ser um parágrafo por função.
• Peça os testes à IA a partir da especificação, deixando claro que ela deve apontar quando a implementação divergir, em vez de ajustar o teste para passar.
• Rode a suíte e leia cada falha. Falha inicial não é problema: pode ser o primeiro defeito encontrado.
• Revise as asserções com a lista da seção anterior e rejeite os testes que só conferem ausência de erro.
• Aplique falhas propositais nos pontos de maior risco ou rode a ferramenta de mutação no módulo.
• Para cada mutante sobrevivente relevante, adicione um teste que o mate e registre a regra protegida.
• Faça um commit separado para os testes, com descrição de como foram gerados e validados.
• Rode a suíte novamente em integração contínua, para que a proteção não dependa da máquina de uma pessoa.

Se os prompts de geração de testes se repetem na equipe, vale transformá-los em uma instrução reutilizável. O artigo sobre skills no Claude Code mostra como padronizar esse tipo de procedimento, e o guia de adoção do Claude Code para equipes trata de limites e revisão no uso diário.

Se o sistema testado inclui um agente de IA com respostas variáveis, o raciocínio é parecido, mas o instrumento é outro: conjuntos de avaliação e regressão. O texto sobre teste de regressão de prompts no CI cobre esse caso, e a documentação de avaliações da OpenAI e da Anthropic, listadas nas fontes, explica a lógica de medir comportamento com critérios definidos antes.

Como aplicar isso com controle na equipe

O método que usamos em projetos de IA vale também para testes gerados: mapear, limitar, pilotar e transferir. Mapear significa identificar quais módulos têm regra de negócio sensível e qual é o risco de um defeito silencioso ali. Limitar é decidir onde a IA pode gerar testes sozinha (código utilitário, formatação) e onde só gera rascunho para revisão (cálculos, permissões, dados pessoais sob a LGPD).

Pilotar é escolher um módulo, gerar os testes, aplicar mutação ou falha proposital e registrar o que aconteceu: quantos testes foram aceitos sem mudança, quantos foram reescritos e quais defeitos reais apareceram. O critério de sucesso deve ser combinado antes, e o texto sobre como medir um piloto de automação com IA ajuda a definir métricas e pontos de decisão. Transferir é deixar o procedimento documentado para a equipe operar sem depender de quem o montou, e então decidir se amplia, ajusta ou interrompe.

Um cuidado a mais: testes costumam usar dados de exemplo. Não cole dados reais de clientes em prompts nem em fixtures. Use dados sintéticos e siga a política interna de uso de IA.

O que é documentação oficial das ferramentas, o que é prática de engenharia e o que é hipótese a testar na sua base de código deve ficar separado nos registros. Não há garantia de que uma técnica funcione igual em qualquer linguagem ou projeto, por isso o piloto existe.

Perguntas frequentes

Testes gerados por IA são confiáveis? Podem ser, desde que validados. A IA escreve testes rápido, mas costuma refletir o comportamento do código em vez da regra de negócio. Trate o lote como rascunho até passar por revisão de asserções, falha proposital ou teste de mutação.

Teste de mutação vale a pena para toda a base de código? Normalmente não no começo, porque a técnica é mais lenta que uma suíte comum. Comece pelos módulos críticos, como cálculo, permissões e integrações, e amplie se o resultado justificar o tempo. Consulte a documentação da ferramenta da sua linguagem para configurar o escopo.

Cobertura alta de testes garante qualidade? Não. Cobertura mede o que foi executado, não o que foi conferido. Testes sem asserção ou com asserção fraca podem manter a cobertura alta e não proteger nada, por isso é preciso combinar cobertura com mutação, falha proposital e revisão das asserções.

Devo deixar a IA corrigir o teste quando ele falha? Com cuidado. Se o teste foi escrito a partir da especificação e falha, o defeito pode estar no código, e ajustar o teste para passar esconde o problema. Peça à IA que explique a divergência e decida com base na regra de negócio, não na vontade de ver tudo verde.

Fontes

• Anthropic: Demystifying evals for AI agents
• OpenAI: Evals guide
• NIST AI Risk Management Framework