Testes escritos por IA, passo a passo: como o Claude escreveu 4.722 dos meus 5.247 testes — incluindo o prompt para copiar e colar que gera uma suite de testes completa em 15 minutos.
Não tens de escrever testes para ter testes. Trata os testes como uma funcionalidade: dá à IA um briefing estruturado e ela gera uma suite abrangente em cerca de 15 minutos. O meu produto tem 5.247 testes. O Claude escreveu 4.722 deles — 90%. Eis o método exato, incluindo o prompt que podes copiar.
No artigo anterior contei a história do bug que aprovou 15 candidaturas de startups com um clique — o bug que finalmente me convenceu de que os testes são um seguro, não um custo. Este artigo é a outra metade: como um fundador a solo, não técnico, consegue de facto milhares de testes sem gastar uma única noite a escrevê-los.
Trata os testes como uma funcionalidade, não como uma tarefa chata
O erro que a maioria das pessoas comete é pedir à IA "escreve-me um teste para esta função". Isso dá-te testes superficiais e decorativos — do tipo que passa aconteça o que acontecer.
A solução é dar aos testes o mesmo tratamento que dás à construção de funcionalidades: um briefing estruturado que diz o que testar, que padrões seguir e como verificar o resultado. Uso o mesmo formato de documento que uso para funcionalidades — o método PRP — apontado aos testes. Um PRP de testes leva cerca de cinco minutos a escrever e produz uma cobertura que um humano aborrecido nunca produziria.
Um exemplo real: 28 testes em 15 minutos
Na semana passada construí um novo serviço que gere as histórias de sucesso dos antigos participantes da aceleradora — criá-las, publicá-las, arquivá-las. Doze operações distintas. O eu de antigamente tê-lo-ia lançado sem testes e depurado em produção. Em vez disso:
| Passo | Tempo |
|---|---|
| Escrever o PRP de testes (o briefing) | 5 minutos |
| O Claude gera a suite de testes — 247 linhas, 28 casos de teste | 10 minutos |
| Correr os testes, rever duas falhas | 2 minutos |
| O Claude corrige os dois problemas, passam todos os 28 | 3 minutos |
Eis a parte que vale a pena ler duas vezes. Dos dois testes que falharam, um era uma discrepância de nomes na preparação do teste — trivial. O outro apanhou um bug real no meu serviço: permitia publicar uma história de sucesso sem as métricas preenchidas. A suite de testes encontrou um bug de produção antes de a produção o encontrar, no primeiro dia da sua existência.
Cobertura final: 94,2% do serviço. Escrever esses 28 casos de teste à mão teria levado 3,5–4,5 horas. O caminho da IA levou 15 minutos — 14–18x mais depressa.
O prompt de testes para copiar e colar
Este é o esqueleto de todos os PRP de testes que escrevo. Preenche o que está entre parênteses retos, cola-o na tua ferramenta de programação com IA e pede-lhe que gere a suite:
Objetivo: cobertura de testes abrangente para [nome da funcionalidade]. Meta de cobertura: 90%+.
Funcionalidade a testar: [o ficheiro] e a lista das suas operações — cada função que queres coberta, pelo nome.
Padrões a seguir: cola um ou dois testes bem escritos do teu código, para que a IA copie o teu estilo em vez de inventar um.
Cenários a cobrir: o caminho feliz; casos-limite (entradas vazias, valores em falta, condições de fronteira); condições de erro (dados inválidos, falhas da base de dados, acesso não autorizado); e as tuas regras de negócio, escritas em linguagem simples — "uma candidatura rejeitada nunca pode ser aprovada", "os utilizadores só podem ver os dados da sua própria organização".
Ciclo de validação: os comandos exatos para correr os testes e verificar a cobertura, para que a IA possa verificar o próprio trabalho e corrigir falhas antes de te devolver o resultado.
Armadilhas: tudo o que já te mordeu antes — mudanças de estado irreversíveis, campos que têm de existir antes de publicar.
A linha das regras de negócio é a que mais compensa. Cada regra em linguagem simples que escreves torna-se um teste que a protege para sempre — é exatamente o tipo de teste que teria apanhado o meu bug das 15 aprovações.
Porque é que a IA testa melhor do que os humanos
Depois de gerar milhares de testes desta forma, vou dizer uma coisa desconfortável: a IA é melhor a testar do que a maioria dos programadores. Não mais inteligente — mais minuciosa, por quatro razões.
Não se aborrece. Os humanos saltam casos-limite porque "isto já chega". A IA gera todos os casos que especificares, de forma exaustiva.
Segue padrões na perfeição. Mostra-lhe um bom teste e ela aplica o padrão às doze operações. Sem erros de copiar e colar, sem verificações esquecidas.
Encontra casos que te escapariam. Na minha suite das histórias de sucesso, o Claude acrescentou casos-limite que eu não tinha listado: texto vazio versus texto em falta, números negativos nas métricas, entradas maliciosas nos filtros de pesquisa, duas mudanças de estado contraditórias ao mesmo tempo.
Atualiza os testes quando o código muda. Refatora o serviço, volta a correr o briefing e a suite inteira regenera-se em minutos. "Os testes estão desatualizados" deixa de ser desculpa.
As funcionalidades exigem criatividade. Os testes exigem minúcia. A IA destaca-se na minúcia — e é por isso que testar, e não construir funcionalidades, pode ser a melhor utilização da IA para um fundador a solo.
Torna-o automático
O ponto de chegada é simples: cada funcionalidade sai com testes, gerados na mesma sessão que a própria funcionalidade. Nada de "depois". Nada de um sprint de testes à parte. O briefing leva cinco minutos, a suite leva dez, e o ciclo de validação faz com que a IA corrija as próprias falhas antes sequer de olhares.
Desde que adotei este fluxo de trabalho, não lancei nenhum bug crítico para produção em quatro meses — com 82% de cobertura num produto em que o padrão do setor para uma startup financiada é 60–70%. O seguro é hoje quase gratuito. A única decisão que resta é se continuas a recusá-lo.
Perguntas frequentes
Os testes escritos por IA são mesmo bons?
Com um briefing estruturado, sim — muitas vezes melhores do que os escritos à mão, porque a IA não salta casos por aborrecimento. Os meus chegaram a 94,2% de cobertura num serviço novo e apanharam um bug real (publicar sem os dados obrigatórios) antes de a funcionalidade chegar aos utilizadores. Sem briefing, obténs testes superficiais — o briefing é a diferença.
O que é um PRP de testes?
Um documento curto e estruturado — cinco minutos a escrever — que diz à IA o que testar: a funcionalidade e as suas operações, um teste de exemplo para copiar o estilo, os cenários a cobrir (caminho feliz, casos-limite, erros, regras de negócio) e os comandos para verificar o resultado. Aplica o método PRP aos testes.
Quanto tempo leva a conseguir cobertura real desta forma?
Cerca de 15 minutos por funcionalidade: cinco para o briefing, dez para a geração e a verificação. A mesma suite escrita à mão levaria 3,5–4,5 horas — 14–18x mais. Essa queda no custo é a razão por que o meu produto tem 5.247 testes em vez dos zero que tinha antes.
Como sei que os testes da IA não são lixo?
Duas verificações. Primeiro, o ciclo de validação: o briefing inclui os comandos para correr os testes e o relatório de cobertura, por isso nada é aceite de fé. Segundo, as regras de negócio: escreve-as em linguagem simples e procura-as nos testes gerados — se "só a candidatura clicada é aprovada" aparece como teste, a suite está a proteger o que importa.