⚖️ 7.3 O Equilíbrio da Pirâmide de Testes
Um erro comum em equipes iniciantes é o “Sorvete de Casquinha Invertido”: pouquíssimos testes de unidade e uma montanha de testes de sistema (Selenium) lentos e frágeis. Para ter sucesso, você precisa Equilibrar a sua Pirâmide.
🏗️ Por que não testar tudo via Browser?
- Fragilidade: Se o designer muda um CSS, 200 testes de sistema quebram.
- Lentidão: 1000 testes de unidade rodam em 2 segundos. 1000 testes de Selenium podem levar 2 horas.
- Dificuldade de Diagnóstico: Se um teste de sistema falha, o erro pode ser no banco, na rede, no JS ou no Java. No teste de unidade, o erro está na linha X da classe Y.
📊 A Pirâmide de Elite
graph TD A[Testes de UI / E2E - Poucos e Críticos] --> B[Testes de API / Integração - O Meio de Campo] B --> C[Testes de Unidade - A Base Sólida] style C fill:#f1f8e9,stroke:#558b2f,stroke-width:2px
🛡️ Estratégia de Cobertura
- 80% Unidade: Teste todos os
if/else, cálculos e regras de domínio. - 15% Integração/API: Teste os contratos, o banco de dados e as permissões.
- 5% Sistema (E2E): Teste apenas os “Caminhos Felizes” (Login → Compra → Checkout).
Feedback é a Moeda 🛡️
O objetivo da bateria de testes é dar feedback rápido ao desenvolvedor. Se o teste demora para rodar, o desenvolvedor para de rodá-lo, e a bateria morre. Mantenha sua base de unidade forte para garantir agilidade. 🏁
Dica de Ouro ⚡
Se você encontrar um bug em produção que o teste de sistema não pegou, não escreva outro teste de sistema. Tente reproduzir o bug com um Teste de Unidade. É mais barato, rápido e evita que o bug volte. 🚀