Pirâmide de testes explicada: unit, integração e E2E
Milhares de unitários, dezenas de integração, uma dúzia de E2E vitais: por que a pirâmide tem essa forma, como diagnosticar a sua e o antipadrão da casquinha de sorvete.
Todo time que sofre com testes sofre de um dos dois jeitos: ou não tem testes e vive apagando incêndio em produção, ou tem os testes errados: uma suíte de ponta a ponta lenta e frágil que quebra por qualquer coisa e que todo mundo ignora.
A pirâmide de testes existe para evitar os dois destinos. Proposta por Mike Cohn e detalhada num dos guias mais citados da área, o Practical Test Pyramid publicado no site de Martin Fowler (martinfowler.com), ela responde a pergunta central: quantos testes de cada tipo o meu produto deveria ter?
A base larga: testes unitários
Testam uma unidade de lógica isolada: uma função de cálculo de frete, uma regra de desconto, uma validação. Rodam em milissegundos, aos milhares, a cada salvamento de arquivo.
- Por que são a base: baratos de escrever, instantâneos de rodar e cirúrgicos no diagnóstico. Quando um quebra, você sabe exatamente qual regra quebrou.
- A condição: lógica de negócio isolada da infraestrutura. É o dividendo direto de fronteiras bem desenhadas, como na Clean Architecture: caso de uso testável sem banco, sem HTTP, sem mock acrobático.
O meio: testes de integração
Verificam se as peças conversam: o repositório grava mesmo no banco? A chamada à API externa trata timeout? A fila entrega o evento?
- Quando usar: em toda fronteira real do sistema (banco, filas, APIs de terceiros). São mais lentos e exigem ambiente, então cobrem as costuras, não a lógica (que já foi coberta embaixo).
- A armadilha: duplicar aqui o que os unitários já garantem. Teste de integração testa integração; parece óbvio, mas é o erro mais comum.
O topo estreito: testes de ponta a ponta (E2E)
Simulam o usuário de verdade: navegador aberto, login, compra concluída. São os mais realistas e também os mais caros: lentos, sensíveis a timing e a mudanças de tela.
- Quando usar: apenas nos fluxos em que o negócio não pode falhar. Login, checkout, contratação. Uma dúzia de cenários vitais, não trezentos.
- A regra de ouro: E2E responde "o sistema inteiro funciona junto?", nunca "a regra X está certa?". Regra se testa na base, mil vezes mais barato.
Por que a forma é de pirâmide (e não de casquinha de sorvete)
O antipadrão clássico é a pirâmide invertida: centenas de testes E2E, quase nada embaixo. O resultado todo mundo conhece: suíte que leva 40 minutos, quebra aleatoriamente ("roda de novo que passa") e treina o time a ignorar vermelho. Teste ignorado é pior que teste ausente, porque dá falsa confiança.
A pirâmide saudável inverte o investimento: quanto mais barato e rápido o teste, mais dele você tem. Milhares de unitários, dezenas ou centenas de integração, uma dúzia de E2E vitais. O feedback chega em segundos no ciclo de desenvolvimento e em minutos na esteira.
Como saber se a sua pirâmide está doente
Três perguntas de diagnóstico:
- Quanto tempo leva a suíte completa? Mais de 15 minutos e os devs param de rodar antes do push.
- Quando um teste quebra, o diagnóstico é imediato? Se cada vermelho exige uma investigação arqueológica, os testes estão no nível errado.
- O time confia no verde? Se "deu verde mas vamos testar na mão" é frase comum, a suíte perdeu a função.
Se alguma resposta doeu, a solução raramente é "escrever mais testes": é redistribuir a pirâmide, empurrando cobertura para baixo.
Da teoria à esteira que segura deploy
Montar essa pirâmide (e a esteira que roda cada camada no momento certo) é o coração do nosso serviço de Qualidade e Testes: diagnóstico da suíte atual, redistribuição por camadas e automação no CI para nenhum vermelho passar despercebido.
Quer o diagnóstico da sua pirâmide? Diga à IA da Rabelo Digital, aqui no canto da tela, quantos testes tem de cada tipo e quanto tempo a suíte leva. Ela devolve a leitura na hora. Sem formulário, sem espera.
Deixe um Comentário