Como gerar testes com IA e descobrir quando eles não provam nada

A IA entrega uma função e, logo depois, uma coleção de testes. Tudo passa. A equipe interpreta o resultado como confirmação de qualidade, mas ainda falta uma pergunta: o que faria esses testes falharem? Se eles apenas reproduzem a lógica escrita pela própria ferramenta, o mesmo erro pode aparecer nos dois lados da comparação e permanecer invisível.

Este é o quinto capítulo da série IA na prática: do protótipo à operação responsável. Vamos construir a diferença entre executar código e verificar um requisito, usando uma demonstração pequena em Delphi. O objetivo é aproveitar a IA para ampliar a análise e preparar testes, sem aceitar uma lista de resultados aprovados como certificado geral de correção.

Para transformar uma demanda em verificações que tenham uma razão para existir, SDD em Delphi aprofunda a ligação entre especificação, critérios de aceite, casos de fronteira, implementação e testes. Conheça a proposta e leia a degustação gratuita para avaliar como levar esse método à próxima revisão de código, em vez de medir qualidade apenas pela quantidade de testes aprovados. Quando o desafio é proteger comportamentos de um sistema existente durante sua evolução, Delphi Vivo oferece o percurso complementar de modernização incremental.

O paradigma: testar uma afirmação, não admirar uma execução

Um teste automatizado prepara uma situação, executa uma operação e verifica um resultado. Uma asserção é a comparação que permite declarar se a condição esperada foi atendida. O resultado esperado precisa ter uma origem confiável: requisito, contrato, regra aprovada ou comportamento que a equipe decidiu preservar.

Oráculo de teste é o nome dado ao mecanismo ou critério que indica qual resultado deve ser considerado correto. A expressão não implica uma ferramenta especial. Para uma função simples, pode ser uma expectativa explícita. Para uma integração, pode envolver dados conhecidos e verificações sobre efeitos produzidos, não somente a resposta exibida.

No trabalho com IA, minha recomendação é separar a definição do resultado esperado da implementação. Não significa proibir a ferramenta de ajudar nos dois momentos. Significa exigir que cada expectativa tenha uma justificativa que não seja “o código retornou isso”. Uma explicação bem escrita não resolve uma referência circular.

Um teste que não detecta determinado defeito pode continuar útil para outro comportamento. Portanto, o título não quer dizer que qualquer teste incompleto seja inútil. A crítica é ao uso de evidência estreita para sustentar uma conclusão ampla. Precisamos saber o que foi verificado e o que permaneceu fora do alcance.

Comece pelo requisito e pelos limites

No capítulo sobre projetos Delphi existentes, usamos um caso fictício de importação. A regra isolada deveria rejeitar um nome vazio ou formado apenas por espaços comuns, aceitar um nome com letras e não modificar o valor recebido. Não definimos uma política completa para nomes internacionais ou caracteres invisíveis.

Transforme esse contrato em exemplos antes de olhar a implementação. Uma cadeia vazia deve ser rejeitada. Três espaços comuns também. O nome Ana deve ser aceito, assim como o mesmo nome com espaços ao redor. Há uma decisão para cada entrada; não estamos simplesmente coletando respostas de uma função.

A IA pode sugerir casos adicionais, como limite de tamanho ou tabulação. Essa ajuda é valiosa quando revela uma pergunta que ainda não foi respondida. Contudo, uma sugestão de caso não pode criar silenciosamente uma regra de negócio. Se a equipe não decidiu como tratar determinado caractere, registre a dúvida e confirme o comportamento desejado.

Essa preparação depende da qualidade do contexto, discutida no capítulo sobre engenharia de contexto. Para gerar testes, o contexto precisa incluir o contrato e o ambiente, não apenas o código. Também precisa indicar quais comportamentos são desconhecidos, para evitar expectativas inventadas.

Uma demonstração executada em Delphi

Preparamos um programa próprio de console, uma aplicação que escreve resultados textuais, usando o compilador Delphi para Win32, versão 30.0. O ensaio foi compilado e executado em 2 de outubro de 2026. Ele não usa banco, interface visual, serviço externo nem biblioteca de testes. O alcance é uma função e duas coleções pequenas de verificações.

A versão que atende ao contrato do ensaio é:

function NomeValido(const Valor: string): Boolean;
begin
  Result := Trim(Valor) <> '';
end;

A primeira coleção verifica somente texto vazio e Ana. A segunda acrescenta três espaços comuns e o nome com espaços ao redor. No programa, a rotina de conferência gera uma exceção quando a resposta diverge da expectativa. A exceção é tratada para registrar a falha e encerrar com código diferente de zero.

Em seguida, inserimos deliberadamente um defeito na cópia de laboratório: retirar a chamada a Trim. Não alteramos um sistema em produção nem um projeto do leitor. A versão defeituosa passa a considerar válido um texto formado apenas por espaços, contrariando o requisito que já havia sido definido.

function NomeValido(const Valor: string): Boolean;
begin
  Result := Valor <> '';
end;

Os quatro cenários foram compilados sem erro. A implementação correta passou com a coleção incompleta e com a ampliada. A implementação defeituosa também passou com a coleção incompleta. Quando executada com a coleção ampliada, porém, falhou no critério e encerrou com código 1. Os outros três cenários encerraram com código 0.

O caso de três espaços explica a diferença. Sem ele, a coleção não distingue as duas implementações: ambas rejeitam vazio e aceitam Ana. Acrescentá-lo não torna a função universalmente correta, mas produz evidência de que aquele defeito específico pode ser detectado. Não medimos ganho de produtividade nem desempenho de qualquer modelo de IA.

O que é teste de mutação

Teste de mutação altera intencionalmente o código sob verificação para observar se os testes percebem a mudança. A introdução do Stryker descreve essa técnica. Uma versão alterada é chamada de mutante; se um teste falha, a alteração foi detectada. Se os testes continuam passando, é necessário investigar por que não houve distinção.

Nossa demonstração segue essa ideia com uma alteração manual e controlada. Não executamos Stryker no Delphi. A documentação consultada apresenta implementações para JavaScript e TypeScript, C# e Scala; ela não sustenta uma recomendação de integração direta daquela ferramenta ao exemplo Delphi.

A documentação dos estados de mutação distingue falha de teste de erro de compilação. Se a alteração nem compila, isso não demonstra que uma asserção detectou o defeito em execução. No ensaio deste artigo, o código defeituoso compilou e a verificação ampliada identificou a divergência.

Fonte: ensaio próprio em Delphi Win32, compilador 30.0, executado em 2 out. 2026. O diagrama representa somente a alteração manual e os casos descritos, não uma avaliação de ferramenta de IA.

Cobertura não é a mesma coisa que capacidade de detectar falhas

Cobertura de código indica quais partes foram executadas durante uma verificação, conforme a instrumentação utilizada. Instrumentação é o mecanismo que registra essa execução. Ela ajuda a encontrar trechos não exercitados, mas não substitui a análise das expectativas. O ensaio aqui não mediu cobertura; não há percentual a apresentar.

Uma função pode ser chamada e produzir um resultado incorreto sem que o teste reclame, se não existir uma comparação pertinente. Também pode ser exercitada com dados que nunca alcançam o problema importante. No nosso caso, chamar a função com Ana não revela o tratamento de um campo composto apenas por espaços.

Por isso, minha proposta de revisão usa perguntas concretas: qual requisito sustenta a expectativa, que entrada alcança o limite relevante e que alteração faria o teste falhar? A última pergunta ajuda a reconhecer verificações frágeis. Não é um método completo de comprovação, mas orienta uma investigação mais útil do que contar casos aprovados.

Evite transformar a demonstração em uma meta de pontuação. Um conjunto de mudanças artificiais não representa todos os defeitos possíveis. Algumas alterações podem não mudar o comportamento observável no contexto considerado. A análise precisa explicar o caso, não apenas buscar um número alto para apresentar no relatório.

Como pedir testes à IA

Comece solicitando uma matriz de casos, isto é, uma relação entre entradas, expectativas e requisitos. Peça que a ferramenta identifique ambiguidades antes de produzir código. A equipe deve poder revisar essa relação sem conhecer todos os detalhes da implementação; é nesse momento que regras esquecidas podem aparecer.

Um pedido ilustrativo seria: “Com base neste contrato, proponha casos válidos, inválidos e de limite. Para cada um, explique a origem do resultado esperado. Não derive expectativas executando a função. Aponte decisões ainda abertas e não mude o requisito para acomodar a implementação.”

Depois da revisão, peça o código de teste compatível com o ambiente declarado. Informe versão do compilador, biblioteca disponível e convenções do projeto. O DUnitX oferece atributos para identificar testes, asserções e rotinas de preparação e encerramento. Sua utilização exige conferir a versão efetivamente usada; este ensaio não instalou nem executou essa biblioteca.

Solicite também o relato do que foi executado. “Os testes devem passar” é previsão, não resultado. Se a ferramenta não dispõe do compilador ou das dependências, o exemplo deve ser apresentado como não executado. Corrigir a descrição da evidência faz parte da qualidade, mesmo quando o código parece plausível.

Não deixe o teste esconder efeitos externos

Para uma rotina que grava no banco, conferir apenas o valor retornado pode deixar a escrita sem verificação. Para um envio de mensagem, conferir uma confirmação visual não demonstra, por si só, a entrega correta. Esses são exemplos de escopos distintos: a expectativa deve corresponder ao efeito que o requisito realmente exige.

Dublês de teste são substitutos controlados de componentes usados na execução. Podem ajudar a isolar uma regra, mas não comprovam o comportamento do componente substituído. Se um serviço fictício sempre responde sucesso, o ensaio poderá verificar o tratamento dessa resposta sem verificar autenticação, rede ou comportamento do serviço real.

Minha recomendação é separar testes da regra isolada de verificações da integração. Descreva a responsabilidade de cada camada. Para o exemplo de nomes, uma etapa futura poderia verificar que a importação informa a rejeição e não persiste o registro inválido. Essa integração não foi executada no artigo e não deve herdar aprovação por associação.

Também mantenha o ambiente de teste afastado da produção. Dados sintéticos, recursos de laboratório e autorização limitada reduzem as consequências de uma verificação equivocada. Não aceite que a IA resolva uma falha do teste apagando a asserção, mudando o resultado esperado ou usando credenciais reais sem uma decisão explícita.

O que registrar na revisão

Um registro útil informa o requisito, o caso preparado, o ambiente, o comando executado e o resultado. Quando houver falha, descreva se ela foi de compilação, infraestrutura ou expectativa. Esses eventos exigem ações diferentes; reuni-los sob a expressão “teste não passou” dificulta a investigação e pode esconder a ausência de execução.

No ensaio próprio, guardamos o programa e as condições de compilação. A seleção da versão defeituosa e da coleção ampliada foi feita por símbolos de compilação. O propósito foi preservar um procedimento reproduzível sem distribuir uma alteração defeituosa em um produto. A execução final voltou à implementação correta com a coleção ampliada.

Para o trabalho diário, priorize verificações que protejam requisitos relevantes e possam ser mantidas pela equipe. A IA pode ajudar a preparar casos e explicar falhas, mas alguém precisa avaliar a relação entre a regra, o teste e a conclusão. Uma coleção grande sem essa relação pode consumir tempo sem responder à dúvida importante.

Conclusão

Testes gerados por IA são úteis quando tornam os requisitos verificáveis, não quando apenas confirmam a implementação que a ferramenta acabou de escrever. O ensaio mostrou uma coleção aprovada que não detectava um defeito conhecido e outra que o identificava ao incluir uma entrada exigida pelo contrato.

A pergunta prática é simples: se este comportamento estivesse errado, a verificação perceberia? A resposta precisa vir de expectativas justificadas e evidência de execução, com limites declarados. Assim, a IA participa da construção de uma rede de proteção sem transformar resultados verdes em uma promessa que os testes não conseguem sustentar.

Se a equipe consegue executar testes, mas ainda não sabe justificar o que eles devem provar, SDD em Delphi aprofunda a ligação entre regras, critérios de aceite e verificação. Confira o sumário e a degustação gratuita para avaliar essa base antes de multiplicar testes gerados a partir de expectativas que ninguém confirmou.

Referências

SILVEIRA, Régys Borges da. Como usar IA em um projeto Delphi existente sem perder o controle. regys.com.br, [s. d.]. Disponível em: https://regys.com.br/como-usar-ia-em-um-projeto-delphi-existente-sem-perder-o-controle/. Acesso em: 2 out. 2026.

SILVEIRA, Régys Borges da. Delphi Vivo. Livros de Régys Borges da Silveira, [s. d.]. Disponível em: https://livros.regys.com.br/delphi-vivo. Acesso em: 2 out. 2026.

SILVEIRA, Régys Borges da. Engenharia de contexto: por que um bom prompt não basta para programar com IA. regys.com.br, [s. d.]. Disponível em: https://regys.com.br/engenharia-de-contexto-por-que-um-bom-prompt-nao-basta-para-programar-com-ia/. Acesso em: 2 out. 2026.

SILVEIRA, Régys Borges da. SDD em Delphi. Livros de Régys Borges da Silveira, [s. d.]. Disponível em: https://livros.regys.com.br/sdd-em-delphi. Acesso em: 2 out. 2026.

STRYKER MUTATOR. Mutant states and metrics. Stryker Mutator, [s. d.]. Disponível em: https://stryker-mutator.io/docs/mutation-testing-elements/mutant-states-and-metrics/. Acesso em: 2 out. 2026.

STRYKER MUTATOR. What is mutation testing?. Stryker Mutator, [s. d.]. Disponível em: https://stryker-mutator.io/docs/. Acesso em: 2 out. 2026.

VSOFT TECHNOLOGIES. DUnitX. GitHub, [s. d.]. Disponível em: https://github.com/VSoftTechnologies/DUnitX. Acesso em: 2 out. 2026.