Testes unitários, de integração e ponta a ponta

As decisões de teste são cinco: o que testar em cada nível, como substituir dependências, como testar com o banco real, o que medir e como evitar testes frágeis.

O que testar em cada nível

Uma regra de desconto com doze casos vira doze testes unitários, que rodam em milissegundos. A consulta que busca os pedidos com desconto vira um teste de integração. E o fluxo de compra com cupom vira um único teste de ponta a ponta.

Formatos de distribuição

Para um backend típico de CRUD com algumas regras, o troféu costuma render mais: os erros moram nas consultas, nas transações e nas integrações, que só aparecem com o banco de verdade.

Dublês de teste

Quando uma dependência é lenta, externa ou imprevisível, ela é substituída por um dublê. Há tipos diferentes:

Um sinal de excesso de mocks: o teste quebra a cada refatoração, mesmo quando o comportamento não mudou, porque está preso à forma como o código chama as dependências.

Testar com o banco real

Usar o banco real nos testes de integração era lento e trabalhoso. Hoje, a forma mais comum é subir o banco num container durante os testes.

A terceira opção parece prática e engana: um teste que passa no SQLite não garante nada sobre o PostgreSQL. O exemplo do nível Conceito, com o ON CONFLICT, depende de um comportamento específico do banco.

Para manter os testes independentes entre si:

• Transação desfeita no fim de cada teste: rápido, mas não serve para testar código que controla as próprias transações.
• Limpar as tabelas antes de cada teste: mais lento, funciona sempre.
• Dados únicos por teste, como e-mails com um sufixo aleatório: os testes podem rodar em paralelo sem se atrapalhar.

Cobertura: um número útil, mas não um objetivo

A cobertura mede quanto do código foi executado pelos testes. Ela mostra o que não está testado, mas não diz se o que foi executado foi conferido.

it("calcula o desconto", () => {
  calcularDesconto(80_000, "DEZ"); // executa todas as linhas
  // e não confere nada
});

Esse teste dá 100% de cobertura na função e não pegaria nenhum defeito. Use a cobertura para encontrar áreas importantes sem teste, e não como meta. Uma meta de cobertura obriga a escrever testes para código trivial e incentiva testes sem conferência.

Uma técnica que mede a qualidade dos testes é o teste de mutação: uma ferramenta altera o código de propósito (troca > por >=, remove uma linha) e confere se algum teste falha. Se nenhum falhar, os testes não estavam conferindo aquele comportamento. Ferramentas: Stryker para JavaScript e C#, mutmut para Python, PIT para Java.

Testes frágeis

Um teste frágil (flaky) às vezes passa e às vezes falha, sem mudança no código. Ele destrói a confiança na suíte: depois de algumas falhas falsas, a equipe passa a ignorar as verdadeiras.

A última linha aconteceu neste próprio site. Um teste de ponta a ponta da busca procurava o tópico "Índices" e esperava que ele aparecesse como "em breve". Quando o tópico foi publicado, o teste falhou, sem nenhum defeito no código. A correção foi fazer o teste escolher um tópico "em breve" a partir do índice de busca, em vez de fixar um nome.

Testes na integração contínua

Resumo da decisão

1. Unitários para regras de negócio e casos-limite, sem banco.
2. Integração com o banco real em container, para consultas, transações e restrições.
3. Ponta a ponta só para os fluxos críticos.
4. Dublês para serviços externos, relógio e aleatoriedade, e não para o que você precisa confirmar.
5. Cobertura para achar lacunas, e não como meta; mutação para medir a qualidade.
6. Falhas investigadas, nunca silenciadas.

O próximo nível mostra o mesmo teste unitário nas cinco linguagens, um teste de integração com Testcontainers e a revisão de testes gerados por IA.