Pirâmide de testes

A pirâmide de testes (test pyramid) é uma diretriz de como distribuir os testes automatizados entre os níveis. A base larga são os testes unitários, que são rápidos, baratos e precisos. O meio são os testes de integração ou de serviço. O topo estreito são os testes end-to-end pela UI, que dão a confiança mais realista, mas são os mais lentos e frágeis. A ideia, popularizada por Mike Cohn, é empurrar cada verificação para o nível mais baixo capaz de pegar o problema.

Exemplo

Pegue uma regra: “pedidos acima de US$ 100 têm frete grátis”.

• Unitário: teste a função de cálculo de frete com US$ 99,99, US$ 100,00 e US$ 100,01. Milissegundos cada, sem navegador.
• Integração/API: chame POST /orders com um carrinho de US$ 120 e verifique se a resposta tem shipping: 0. Isso comprova que a regra está ligada ao serviço.
• End-to-end: um único teste de UI que finaliza a compra de um carrinho elegível e vê “Frete grátis” na página de confirmação.

Você não precisa de dez testes de UI para os valores-limite. Os testes unitários já comprovam a aritmética.

Por que o formato importa

Testes de nível mais alto tocam mais componentes, então uma falha diz menos sobre onde está o bug. Eles também precisam de navegadores, ambientes e massa de dados, o que os torna mais lentos e mais propensos a ficar flaky. Uma suíte formada principalmente por testes de UI (o antipadrão da “casquinha de sorvete”) roda por horas, falha por motivos que não têm nada a ver com a mudança e acaba sendo ignorada.

Críticas e alternativas

A pirâmide é uma heurística, não uma cota. Alternativas como o “testing trophy” dão mais peso aos testes de integração, argumentando que testes unitários cheios de mocks podem passar enquanto o sistema real está quebrado. Os dois modelos concordam no que importa: manter poucos testes de UI lentos e amplos, focados nas jornadas críticas, e obter a maior parte da confiança das camadas mais rápidas. Escolha o equilíbrio com base em onde os seus bugs realmente surgem, e não em uma proporção fixa.