Testes automatizados no vibecoding: como pedir pra IA (e por que isso te salva)

A IA gera código que funciona na demo. Você mostra pro cliente, todo mundo aplaude. Aí um usuário digita algo que você não previu e o app quebra. Em produção. Na frente de quem paga.

Teste automatizado é a rede de segurança que pega isso ANTES. É a diferença entre "acho que funciona" e "sei que funciona".

Este é o tutorial que eu queria ter lido quando comecei. Sem jargão de QA, direto ao ponto.

O que é teste automatizado (sem enrolação)

É código que verifica se o seu código funciona. Roda sozinho. Você escreve uma vez, roda mil vezes.

Exemplo bobo: você tem uma função soma(a, b). O teste diz: "se eu chamar soma(2, 3), o resultado TEM que ser 5". Se um dia alguém quebra a função, o teste grita.

No vibecoding isso é vital. Por quê? A IA gera código que passa no caso óbvio e falha no caso de borda. Teste é o que pega o caso de borda antes do usuário.

Os 3 tipos que importam

Não precisa saber 15 tipos. Precisa saber 3.

1. Teste unitário

Testa uma peça pequena isolada. Uma função, um cálculo, uma validação.

Exemplo: "a função que valida e-mail aceita joao@email.com e rejeita joao@". Rápido de escrever, rápido de rodar.

Quando usar: lógica com regra (cálculo de preço, validação, formatação).

2. Teste de integração

Testa se várias peças funcionam JUNTAS. A rota chama o banco, o banco responde, a resposta volta certa.

Exemplo: "quando eu chamo POST /api/pedido, ele salva no banco e retorna o ID". Testa a peça crítica de ponta a ponta.

Quando usar: o coração do seu app. Login, pagamento, salvar dado. É o mais importante pra vibecoding.

3. Teste end-to-end (e2e)

Simula o usuário de verdade. Abre o navegador, clica, digita, confere o resultado na tela.

Exemplo: "o usuário abre a página, preenche o formulário, clica em enviar, e vê a mensagem de sucesso".

Quando usar: os 2 ou 3 fluxos principais do seu produto. Não teste tudo assim, é lento.

Por onde começar (a ordem certa)

Erro comum: querer testar tudo. Você desiste em 1 hora.

Ordem certa:

1. Teste de integração da fatia mais crítica. A que mais dói se quebrar. Login? Pagamento? Comece por ela.
2. Teste unitário da lógica complexa. Aquele cálculo que ninguém entende direito.
3. 1 teste e2e do fluxo principal. O caminho que 80% dos usuários fazem.

Isso já te dá 80% da segurança com 20% do esforço. É o Protocolo de 5 Camadas na prática: a camada "Testar" não é testar tudo, é testar o que importa.

Como pedir pra IA: prompts prontos

Não peça "escreve testes pro meu código". A IA vai escrever teste que só confirma o que o código já faz, sem pegar bug. Peça com contrato.

Prompt 1: teste de integração de rota

Papel: você é engenheiro sênior especialista em testes.
Se algo ficar ambíguo, pergunta antes de gerar.

Regras:
- Framework: Vitest (não Jest).
- Testar a rota POST /api/pedido de ponta a ponta.
- Mockar o banco (não bater no banco real).
- Cobrir 3 cenários OBRIGATÓRIOS:
  1. Caminho feliz (dados válidos, salva, retorna 200 + ID).
  2. Caso de borda (campo faltando, retorna 400).
  3. Caso de erro (banco offline, retorna 500 sem vazar detalhe).
- NÃO inventar comportamento que o código não tem.
  Se o código não trata um caso, aponta isso em vez de testar errado.

Objetivo: arquivo de teste completo pra rota de pedido.

Modelo: um describe com 3 it, nomes claros em português.

Retorno: só o código do teste + o comando pra rodar.

Prompt 2: teste unitário de lógica

Papel: você é engenheiro sênior de testes.

Regras:
- Framework: Vitest.
- Testar a função calculaFrete(peso, distancia, urgente).
- Cobrir: peso zero, peso negativo (deve dar erro),
  distância grande, urgente vs normal, valores limite.
- Incluir pelo menos 1 caso que eu provavelmente esqueci
  (pensa como usuário mal-intencionado ou distraído).

Objetivo: cobertura real da função de frete.

Modelo: describe + vários it, cada um com 1 asserção clara.

Teste: ao final, liste os casos que você acha que o código
NÃO trata bem e deveria.

Retorno: código do teste + a lista de gaps.

Prompt 3: teste e2e do fluxo

Papel: você é engenheiro sênior de testes e2e.

Regras:
- Framework: Playwright.
- Simular o fluxo: usuário abre /cadastro, preenche nome
  e e-mail, clica em Enviar, vê mensagem "Cadastro confirmado".
- Testar também: se deixar e-mail vazio, mostra erro no campo.
- Seletores por role ou test-id, nunca por classe CSS
  (que muda toda hora).

Objetivo: teste e2e do cadastro que roda no CI.

Modelo: 2 testes (sucesso e erro de validação).

Retorno: código Playwright + o comando pra rodar headless.

Como rodar (o passo que ninguém explica)

Depois que a IA gerou, você roda. Exemplo com Vitest:

# instala (uma vez)
npm install -D vitest

# roda todos os testes
npx vitest run

# roda e fica observando (re-roda quando você salva)
npx vitest

Saída boa:

✓ src/api/pedido.test.ts (3)
  ✓ POST /api/pedido salva e retorna 200
  ✓ campo faltando retorna 400
  ✓ banco offline retorna 500

Test Files  1 passed (1)
     Tests  3 passed (3)

Verde = tá funcionando. Vermelho = quebrou, e o teste te diz onde.

Pra Playwright (e2e):

npm install -D @playwright/test
npx playwright install
npx playwright test

A regra de ouro do vibecoding com teste

Peça o teste ANTES de aceitar o código, não depois.

Fluxo errado (o que quase todo mundo faz):

1. IA gera código.
2. Você cola, roda na mão, parece OK.
3. Aceita.
4. Quebra em produção.

Fluxo certo:

1. IA gera código.
2. Você pede: "agora escreve teste pros casos de borda desse código".
3. Roda o teste.
4. Se passou, aceita. Se falhou, a IA conserta. Aí aceita.

A diferença: no fluxo certo, o bug morre no seu computador, não na frente do cliente.

Vale o ponto

"Teste não é perda de tempo? Eu ando mais rápido sem."

Vale o ponto pra protótipo que você vai jogar fora. Não vale pra nada que vai pra produção.

A conta é simples: escrever teste da fatia crítica leva 20 minutos. Um bug em produção custa: o tempo de descobrir + o tempo de corrigir às pressas + a confiança do cliente que você perdeu. Sempre mais que 20 minutos.

E com IA, os 20 minutos viram 5. Ela escreve, você revisa e roda. Não tem desculpa em 2026.

Conclusão

Teste automatizado não é coisa de empresa grande. É o que te deixa dormir tranquilo com seu app no ar.

Comece pela fatia crítica. Peça pra IA com contrato (casos de borda, framework, sem inventar). Rode antes de aceitar. Repita.

Em 2026, vibecodar sem teste é dirigir sem cinto porque "nunca bati". Bater é questão de tempo. Cinto é 5 minutos.

A decisão é sua.