Unit, integration e e2e

O problema

Muita discussão sobre testes vira disputa de slogan.

Tem time que quer resolver tudo com teste unitario. Tem time que desconfia de tudo e joga quase toda confiança em e2e. Tem time que usa integração para tudo e depois reclama que a suite virou um atoleiro.

O erro central e tratar essas tres camadas como se fossem alternativas equivalentes.

Não sao.

Elas respondem perguntas diferentes.

Modelo mental

O jeito mais útil de pensar e este:

• Teste unitario pergunta: “essa regra funciona isolada?”
• Teste de integração pergunta: “essas partes conversam direito?”
• Teste e2e pergunta: “o fluxo real principal continua funcionando do ponto de vista do usuário?”

Cada camada compra confiança de um jeito diferente:

• unitario e mais barato e mais rápido
• integração pega erro que o isolamento esconde
• e2e valida caminho real, mas custa mais e tende a ser mais fragil

Por isso o ponto não e “qual e melhor?”.

O ponto e:

qual pergunta eu preciso responder agora e qual e a camada mais barata que responde isso com honestidade?

Quebrando o problema

Quando unitario ajuda mais

Teste unitario e forte quando a regra mora em lógica clara:

• calculo
• validação
• transformação
• decisão de estado

Se eu quero saber se o cupom expira certo, se o frete muda com o peso ou se um pedido pode transitar de estado, normalmente um teste pequeno resolve muito bem.

Quando integração ajuda mais

Integração entra quando o risco esta na costura.

Exemplos comuns:

• API recebendo payload, validando e persistindo
• serviço lendo banco e publicando em fila
• componente disparando rede e atualizando estado

Aqui, o problema não e mais “a função faz conta certa?”.

O problema e:

essas pecas realmente se encaixam do jeito que eu imagino?

Quando e2e ajuda mais

e2e faz mais sentido em fluxo crítico de negócio:

• login
• checkout
• recuperação de senha
• criação de conta
• publicação principal do produto

Esse tipo de teste protege o caminho que o usuário vive de verdade.

Mas ele não deveria carregar o peso de provar cada regra interna do sistema.

Se tentar fazer isso, a suite fica lenta, fraca para diagnostico e cara de manter.

Exemplo simples

Imagine um fluxo de compra.

Você pode testar assim:

• unitario: calculo do total, aplicação de desconto e validação de estoque
• integração: endpoint de checkout falando com banco e registrando pedido corretamente
• e2e: usuário adiciona item ao carrinho, paga e ve confirmação

Agora compare dois extremos ruins.

Extremismo 1: tudo em unitario

Você mocka banco, gateway, fila, frontend e navegador.

Resultado: as regras pequenas passam, mas a costura real pode estar quebrada.

Extremismo 2: tudo em e2e

Você tenta validar cupom, frete, erro de pagamento, estoque, permissao e texto da tela no browser.

Resultado: demora, flakiness e dificuldade para entender por que falhou.

O desenho melhor costuma ser:

regra pequena em teste pequeno, costura em integração e experiência crítica em poucos e2e bem escolhidos.

Erros comuns

• Usar e2e para compensar falta de clareza sobre arquitetura de testes.
• Mockar demais no unitario e concluir que o sistema inteiro esta protegido.
• Repetir o mesmo cenario em todas as camadas sem ganhar informação nova.
• Fazer integração que na prática ainda e unitario com um monte de stub.
• Medir qualidade da suite pela quantidade de testes, não pela capacidade de detectar regressao cedo.

Como um senior pensa

Quem tem mais experiência para de discutir formato de piramide como se fosse religiao.

Passa a pensar em retorno por camada.

O raciocínio costuma ser:

“Quero colocar a maior parte da verificação na camada mais barata que ainda encosta no risco real. Se eu preciso subir de camada para ficar honesto, eu subo. Mas não antes.”

Isso tira a conversa do dogma e leva para custo, velocidade e tipo de falha.

O que o entrevistador quer ver

Em entrevista, o avaliador normalmente não quer que você recite “muitos unitarios, alguns de integração, poucos e2e” e pare por ai.

Ele quer ver se você:

• entende a função de cada camada
• sabe escolher pela pergunta que precisa responder
• percebe o custo e a fragilidade de cada uma
• evita tanto o isolamento fake quanto a dependência exagerada de e2e

Uma resposta forte costuma soar assim:

“Eu não escolho a camada por preferencia pessoal. Escolho pelo tipo de risco. Regra isolada vai para unitario. Costura vai para integração. Fluxo crítico do usuário ganha poucos e2e. O objetivo e detectar o erro certo o mais cedo possível.”

Maturidade em testes não e amar uma camada. E saber o que cada camada compra e quanto ela custa.