Testes gerados por IA: cobertura não é confiança

Pedir testes ao modelo é provavelmente o uso de IA com melhor aceitação em qualquer time: ninguém gosta de escrever teste para código legado, a cobertura sobe rápido e o gráfico fica bonito. É também onde a ilusão de qualidade se instala com mais facilidade.

Cobertura mede execução, não verificação

Cobertura responde uma pergunta só: essa linha rodou durante a suíte? Ela não responde se alguém verificou o resultado.

É trivial escrever um teste que executa cem linhas e não afirma quase nada. Se o modelo gerar cem testes assim, você terá 90% de cobertura e uma suíte que continua verde depois de uma mudança que quebrou o comportamento.

A pergunta útil não é "quanto do código foi coberto?", é "se eu quebrar esse comportamento de propósito, algum teste falha?".

O teste gerado a partir do código herda o bug

Esse é o problema estrutural, e não tem solução por prompt melhor.

Quando você dá a implementação ao modelo e pede o teste, ele descreve o que o código faz. Se a regra de negócio está implementada errado, o teste gerado passa a proteger o erro. Pior: a partir daí, corrigir o bug quebra o teste, e alguém vai "consertar o teste".

A alternativa é gerar teste a partir da especificação, do ticket, da regra escrita, e só depois rodar contra a implementação. Quando os dois discordam, você aprendeu alguma coisa. É o espírito do TDD, com a ordem preservada.

Onde a geração automática realmente ajuda

Três casos com retorno claro:

• Código legado sem cobertura nenhuma. Aqui até um teste de caracterização, que só congela o comportamento atual, tem valor: ele serve de rede antes de refatorar.
• Casos de borda que ninguém lembra. Pedir a lista de entradas limite (vazio, nulo, negativo, unicode, limites numéricos) é onde o modelo rende mais.
• Platôs de cobertura. Pesquisa apresentada na ICSE 2023 mostrou que usar um LLM para destravar geração de testes baseada em busca ajuda exatamente quando a técnica automática empaca, que é o ponto em que ela costuma parar sozinha.

Vigie a flakiness

Volume grande de testes gerados aumenta o risco de teste instável, e teste instável custa mais caro do que parece. A engenharia do Google publicou que cerca de 1,5% dos seus testes são flaky, e que eles consomem tempo e confiança de forma desproporcional.

O efeito prático é conhecido: quando falha vermelha vira ruído, o time para de olhar. Uma suíte com muitos testes instáveis é pior do que uma suíte menor e confiável.

Regra simples: teste que falha de forma intermitente sai da barreira de bloqueio no mesmo dia, vira item de correção, e só volta quando for determinístico.

Tamanho do teste importa mais do que quantidade

A prática de engenharia de testes do Google organiza a suíte por tamanho, e não por camada teórica: testes pequenos rodam em um processo, sem rede nem disco; médios podem usar localhost; grandes podem usar recursos externos. O objetivo é previsibilidade e velocidade.

Quando a IA gera testes em volume, a tendência é produzir testes médios e grandes disfarçados de unitários, porque o modelo não sabe quais dependências você considera caras. Vale checar isso explicitamente: se a suíte unitária ficou lenta depois da adoção, é esse o motivo.

Como verificar que a suíte tem dentes

Um exercício barato e revelador: pegue três regras de negócio importantes, quebre cada uma de propósito no código e rode a suíte. Se nenhum teste ficar vermelho, a cobertura não está protegendo nada.

Isso é uma versão manual e pobre de teste de mutação, e é suficiente para decidir onde investir. Se quiser ir além, ferramentas de mutação automatizam a ideia, mas comece pelo exercício manual: ele custa uma hora e costuma mudar a conversa sobre metas de cobertura.

O que isso significa para o seu time

Pare de usar percentual de cobertura como meta e passe a usar como sinal de alerta apenas quando cair. Adote o exercício das três regras quebradas uma vez por trimestre.

Ao gerar teste com IA, gere a partir da regra escrita, não do código, sempre que a regra existir. E quando o teste for de caracterização de legado, marque isso no nome do arquivo: quem vier depois precisa saber que aquele teste descreve o comportamento atual, e não o comportamento desejado.