Uma suíte de testes gerados por inteligência artificial pode parecer madura e ainda assim proteger pouco. O risco começa quando o teste verde funciona como certificado de segurança, mas não falharia diante do comportamento errado. Quando ele apenas confirma o caminho feliz, repete a implementação ou verifica chamadas internas sem efeito observável, aumenta a sensação de segurança sem aumentar a confiança na regra que o software deveria preservar.
O sinal de alerta é o teste bonito que só confirma a implementação
Um problema recorrente na revisão de testes gerados por IA é confundir acabamento com evidência. Eles vêm bem nomeados, agrupados, com estrutura familiar e mensagens claras. Passam no pipeline. À primeira vista, parecem prontos para entrar na suíte.
Mas aparência não é evidência.
Um teste frágil pode chamar a função certa, montar dados plausíveis e verificar que alguma coisa aconteceu. Ainda assim, ele não demonstra que a regra de negócio foi protegida. Em muitos casos, a verificação é tão próxima da implementação que o teste falha quando o código é reorganizado, mas passa quando a regra é violada.
Para a liderança de engenharia, qualidade e produto, esse é o pior tipo de teste: caro para manter e fraco para denunciar erro.
A origem por IA não torna o teste automaticamente ruim. Um teste escrito por uma pessoa também pode ser frágil. Em revisões internas, trate volume e bom acabamento como possíveis fontes de complacência, não como evidência de qualidade. A revisão precisa compensar esse risco: menos encantamento com a forma, mais investigação sobre o erro que o teste conseguiria detectar.
O DORA recomenda tratar testes como parte do desenvolvimento, combinando automação com atividades manuais, como exploração e usabilidade, além de manter e revisar as suítes de teste ao longo do tempo DORA. Essa recomendação ajuda a enquadrar o problema: teste automatizado não é um artefato que entra na base e fica imune à crítica. Ele também precisa ser revisado.
Se a organização está discutindo uma prática mais ampla de qualidade de software com IA, a pergunta sobre testes frágeis é uma peça específica desse sistema. Ela não resolve aceitação, observabilidade, revisão de código ou decisão de produção. Mas evita que uma suíte crescente vire apenas um relatório verde.
A pergunta central é: que erro faria este teste falhar?
A revisão de testes gerados por IA deveria começar por uma pergunta simples: que erro concreto este teste detectaria?
Não basta responder “ele testa a função de desconto” ou “ele testa o componente de checkout”. Isso nomeia uma área do código, não um comportamento protegido. Uma resposta melhor seria: “este teste falha se um cupom expirado for aceito”, “este teste falha se um pedido abaixo do valor mínimo receber desconto” ou “este teste falha se o sistema permitir acumular cupons proibidos”.
A diferença parece pequena. Não é.
Quando você nomeia o erro detectável, desloca a revisão da execução para a decisão. O teste deixa de ser uma prova de que o código roda e passa a ser uma barreira contra um comportamento indesejado.
Na prática, procure erros como:
- inverter uma condição relevante;
- aceitar um status que deveria ser recusado;
- ignorar um limite de valor, prazo ou quantidade;
- devolver uma mensagem incompatível com a regra;
- aplicar uma transformação quando a entrada deveria ser rejeitada;
- permitir uma combinação que o produto proíbe.
Se nenhum desses erros faria o teste falhar, o teste talvez esteja medindo atividade, não qualidade.
Essa pergunta também ajuda a separar testes redundantes de testes complementares. Duas verificações podem ter nomes diferentes e cobrir o mesmo comportamento. Por outro lado, um único fluxo pode precisar de casos diferentes quando cada um protege uma decisão distinta do produto.
Esse raciocínio conversa com o tema de critérios de aceite para funcionalidades de IA, mas aqui o foco é mais estreito: o que um teste automatizado consegue denunciar quando o código se comporta de forma errada.
A mutação de comportamento pode ser leve, sem virar um processo pesado
Uma forma prática de revisar testes frágeis é imaginar uma mutação de comportamento. Ou seja, uma alteração errada na regra esperada.
Isso não precisa começar como uma ferramenta formal de mutation testing. Pode ser uma prática de revisão. O revisor escolhe um teste relevante, imagina uma mudança incorreta no código e pergunta se a asserção pegaria essa mudança.
O procedimento pode ser simples:
- escolha um teste que protege uma regra relevante;
- escreva em linguagem natural o comportamento que deveria ser proibido;
- imagine uma alteração errada no código que permitiria esse comportamento;
- verifique se a asserção atual falharia;
- decida se o teste deve ser mantido, corrigido, complementado ou removido da suíte crítica.
A palavra “crítica” importa. Nem todo teste precisa receber o mesmo nível de escrutínio. Testes que protegem regras de negócio, integrações sensíveis, permissões, cálculos, estados e fluxos de decisão merecem mais atenção do que testes de baixo risco sobre formatação ou apresentação simples.
Essa prática também evita uma armadilha comum: exigir que todo teste conheça todos os cenários. Um bom teste não precisa provar tudo. Ele precisa declarar o comportamento que protege e falhar quando aquele comportamento for violado.
A Anthropic, ao tratar de avaliações de agentes, distingue a trajetória de execução do resultado efetivo no ambiente. Uma mensagem dizendo que a tarefa terminou não basta para comprovar o resultado; avaliações usam entradas, critérios de sucesso e verificadores Anthropic. A comparação tem limite, porque testar código e avaliar agentes não são a mesma coisa. Ainda assim, a distinção é útil: execução aparente não equivale a resultado correto.
Em testes automatizados, o equivalente é claro. Um pipeline verde não prova que o comportamento errado seria detectado. Ele prova que, para aquelas entradas e asserções, nada falhou.
Exemplo fictício: cupom aplicado fora da regra permitida
Considere um exemplo fictício de comércio eletrônico. A equipe pede a uma IA que gere testes para a função de aplicação de cupom. A regra de produto diz que um cupom só pode ser aplicado se estiver ativo, dentro do prazo, acima do valor mínimo e sem combinação com outro cupom.
A IA gera um teste com bom nome: “deve aplicar cupom válido ao carrinho”. O teste cria um carrinho, adiciona um cupom e verifica que o total final mudou.
Isso protege alguma coisa, mas pouco. Ele pode passar mesmo se o sistema aceitar cupom expirado em outro cenário. Pode passar se cupons cumulativos forem permitidos indevidamente. Pode passar se o valor mínimo for ignorado, desde que o caso montado esteja confortavelmente acima do limite.
A revisão por mutação de comportamento perguntaria:
- se o código aceitasse um cupom expirado, qual teste falharia?
- se o código aplicasse desconto abaixo do valor mínimo, qual teste falharia?
- se o código permitisse dois cupons que não podem ser combinados, qual teste falharia?
- se o sistema retornasse sucesso, mas não registrasse o motivo da recusa quando necessário, qual teste falharia?
O teste original, que apenas verifica se o total mudou, não responde a essas perguntas. Ele confirma o caminho permitido, mas não desafia as fronteiras da regra.
Uma suíte mais forte teria testes com intenção explícita. Um caso afirmaria que um cupom ativo e elegível reduz o total. Outro afirmaria que um cupom expirado é recusado e preserva o total. Outro forçaria o valor exatamente no limite definido pela regra. Outro colocaria o carrinho imediatamente fora do limite. Outro verificaria a combinação proibida.
Nenhum desses testes garante que o produto não terá falhas. O efeito esperado é mais modesto e mais honesto: aumentar a chance de que alterações erradas em regras relevantes sejam denunciadas cedo. Esse efeito precisa ser observado na prática da equipe, não presumido como resultado automático.
Checklist: este teste detecta o comportamento errado?
Use este checklist como uma revisão comentada de testes gerados por IA. Os critérios abaixo são uma proposta prática para examinar a força dos testes.
Comportamento protegido
O teste declara qual regra de negócio ou comportamento observável está protegendo?
Se a resposta for apenas o nome de uma função, classe, endpoint ou componente, o teste precisa ser reescrito em torno do comportamento. Um bom nome ajuda, mas a asserção também precisa apontar para uma consequência verificável.
Erro detectável
É possível nomear um erro específico que faria este teste falhar?
Se ninguém consegue dizer qual bug seria capturado, há um sinal forte de falso positivo em teste: ele passa, ocupa espaço na suíte, mas contribui pouco para a confiança.
Entrada que força decisão
Os dados usados no teste obrigam o código a escolher entre aceitar, rejeitar, calcular, bloquear ou transformar algo?
Entradas genéricas demais produzem testes confortáveis. Elas mostram que o fluxo básico roda, mas não pressionam a regra. Prefira dados que exponham uma condição de decisão.
Asserção sobre efeito observável
A verificação confirma um resultado percebido pelo usuário, por um sistema consumidor ou por uma regra de negócio?
Asserções sobre chamadas internas, mocks e detalhes de implementação podem ter valor em contextos específicos. O risco aparece quando elas substituem a verificação do efeito. Se o comportamento correto permanecer igual, uma refatoração não deveria quebrar o teste sem motivo.
Caso negativo
Existe pelo menos um teste mostrando o que não deve acontecer?
Na revisão, desconfie de suítes que só confirmam caminhos válidos. A regra, porém, muitas vezes mora na recusa: o que bloquear, quando rejeitar, quando preservar o estado e quando explicar a falha.
Limite relevante
O teste cobre algum limite que mudaria a decisão do sistema?
Valores confortáveis raramente revelam fragilidade. Um limite relevante merece pelo menos um caso no ponto de decisão e outro fora dele, quando isso fizer sentido para a regra.
Resistência à implementação alternativa
O teste continuaria válido se a implementação mudasse, mas o comportamento correto fosse preservado?
Se a resposta for não, o teste pode estar acoplado demais à solução atual. Esse tipo de acoplamento torna refatorações mais caras sem necessariamente proteger melhor o produto.
Quando manter, corrigir ou descartar um teste gerado por IA
A revisão não precisa virar uma caça a testes gerados por IA. Precisa produzir uma decisão.
Mantenha o teste quando ele declara um comportamento relevante, usa entrada que força uma decisão e falha diante de uma mutação errada plausível. Ele não precisa ser perfeito. Precisa proteger algo que a equipe reconhece como relevante.
Corrija o teste quando a intenção é boa, mas a asserção é fraca. Isso acontece quando o teste monta o cenário certo, mas verifica apenas que uma função foi chamada, que um objeto existe ou que um fluxo terminou. Nesses casos, a melhor decisão costuma ser trocar a verificação por um efeito observável.
Complemente o teste quando ele cobre apenas o caminho feliz de uma regra que também depende de recusas, limites ou exceções. O teste afirmativo pode continuar útil, desde que não seja vendido como cobertura de comportamento suficiente.
Descarte o teste quando ele replica a implementação, protege detalhe sem valor para o produto ou aumenta ruído na suíte sem capturar uma decisão relevante. Remover um teste fraco pode ser melhor do que preservá-lo por apego à contagem de cobertura.
Cobertura de código e cobertura de comportamento não são sinônimos. A primeira pode indicar que linhas foram exercitadas. A segunda exige perguntar se decisões relevantes foram desafiadas.
Essa distinção também vale quando a equipe revisa código produzido com assistência de IA. Em como revisar código gerado por IA, o ponto central é não confundir plausibilidade com correção. Nos testes, a mesma disciplina aparece de outro jeito: não confundir suíte organizada com proteção real.
O que automatizar e o que ainda precisa de revisão humana
A IA pode sugerir variações, nomes, estruturas de teste e casos iniciais. Isso pode ser útil, desde que a equipe não terceirize a escolha do comportamento que merece proteção.
Essa escolha depende de regra de negócio, risco, histórico do produto, expectativa do usuário e custo de falha. A IA pode sugerir possibilidades, mas a equipe precisa decidir quais decisões do sistema não podem mudar sem alarme.
Também há testes que não devem ser tratados apenas como automação unitária. O DORA inclui atividades manuais, como exploração e usabilidade, na abordagem de qualidade ao longo do desenvolvimento DORA. Já o Google SRE discute lançamentos graduais, avaliando mudanças em uma parcela do tráfego antes de ampliar a exposição Google SRE. Essas práticas não substituem bons testes, mas lembram que qualidade não cabe em uma única camada.
Para funcionalidades com maior incerteza, a pergunta sobre testes frágeis deve se conectar a outras decisões: critérios de aceite, revisão técnica, testes exploratórios, observabilidade, lançamento gradual e plano de reversão. Para funcionalidades simples, o checklist pode bastar como filtro de revisão.
A decisão concreta é examinar cada teste relevante procurando uma mutação simples no comportamento esperado. Se uma alteração errada no código não fizer o teste falhar, o teste deve ser reescrito, complementado ou removido da suíte crítica.
Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.
Leituras para continuar
Fontes
Para continuar esta leitura
Conversar sobre a aplicação na empresa
Conversa sobre o contexto da empresa de software
Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.