A pirâmide de testes ainda faz sentido? Críticas, trophy e como equilibrar

Sua suíte de testes demora 40 minutos para rodar, falha de forma aleatória em metade dos pull requests e mesmo assim um bug óbvio escapou para produção na semana passada. O time tem milhares de testes — só que a maioria são testes de ponta a ponta lentos e frágeis, simulando o navegador inteiro para verificar uma regra de negócio que caberia em três linhas de teste unitário. Esse cenário é o sintoma clássico de uma pirâmide de testes de cabeça para baixo, e ele levanta uma pergunta legítima: depois de mais de quinze anos, a pirâmide de testes ainda faz sentido?

A resposta curta é "sim, mas". O modelo continua sendo o melhor ponto de partida para pensar sobre custo, velocidade e confiança de uma suíte. O que mudou foi o contexto — microsserviços, front-ends que dependem de back-end, serverless — e por isso vale entender o conceito original, as críticas modernas e como calibrar as proporções sem virar refém de um desenho.

O que a pirâmide de testes diz, de verdade

Mike Cohn popularizou a pirâmide em 2009 no livro Succeeding with Agile. A ideia é organizar os testes em camadas por custo e velocidade:

• Base larga — testes unitários. Rápidos (milissegundos), isolados, baratos de escrever e manter. Devem ser a maioria.
• Meio — testes de integração. Verificam que módulos, banco de dados, filas e serviços conversam entre si. Mais lentos e mais caros.
• Topo estreito — testes ponta a ponta (e2e). Simulam o usuário real atravessando o sistema inteiro. Lentos, frágeis, caros. Devem ser poucos.

O recado central não é "escreva exatamente 70% unitário, 20% integração, 10% e2e". É econômico: quanto mais alto na pirâmide, mais lento e mais frágil o teste, então prefira empurrar a verificação para a camada mais baixa que ainda lhe dá confiança. Um teste unitário que falha aponta para uma função; um e2e que falha pode ser rede, timing, seletor de CSS ou um bug de verdade — você gasta tempo investigando antes de saber.

O anti-padrão mais comum tem nome: o cone de sorvete (ice cream cone), a pirâmide invertida. Muito e2e e teste manual no topo, quase nada de unitário na base. É exatamente o cenário de 40 minutos de suíte instável do início.

As críticas modernas: trophy e honeycomb

A pirâmide nasceu num mundo de aplicações monolíticas. Em arquiteturas modernas, parte da lógica vive na fronteira entre componentes — e é aí que as críticas ganham força.

Testing Trophy (popularizado por Kent C. Dodds, no contexto de front-end). Inverte a ênfase: a base é análise estática (TypeScript, ESLint, type-checking) — que pega uma classe inteira de erros sem custo de runtime —, o corpo maior são testes de integração, e unitário/e2e ficam menores. O argumento: numa UI React/Svelte moderna, testar um componente totalmente isolado, com tudo mockado, dá pouca confiança e quebra a cada refactor. O famoso lema do Dodds: "the more your tests resemble the way your software is used, the more confidence they give you".

Testing Honeycomb (Spotify). Foca em testes sociáveis de integração no meio, com poucos testes de implementação isolada e poucos e2e. Pensado para microsserviços, onde o valor está em verificar a interação entre serviços, não a unidade isolada.

Martin Fowler, no artigo On the Diverse And Fantastical Shapes of Testing, dá o veredito sensato: as formas diferentes não se contradizem, elas refletem contextos diferentes. A pergunta certa não é "qual desenho é o correto", e sim "onde está o risco e a complexidade do meu sistema?".

O que mudou de verdade: o peso do meio subiu

O denominador comum das críticas é que a camada de integração ficou mais valiosa do que a pirâmide clássica sugeria. Três motivos:

1. Front-ends dependem de back-end. Componentes de UI raramente são lógica pura; testá-los isolados com mocks pesados testa o mock, não o sistema.
2. Microsserviços movem os bugs para as fronteiras. A unidade pode estar perfeita e o sistema quebrar no contrato entre serviços.
3. Test doubles em excesso geram falsa confiança. Se você mocka tudo, o teste passa mesmo quando a realidade mudou.

Isso não destrói a pirâmide — desloca o equilíbrio. A base de unitários continua sendo onde você cobre lógica de negócio densa (cálculos, validações, regras condicionais), justamente o tipo de coisa discutida em Testes unitários: o que testar, que entra no detalhe de o que merece um unitário. Aqui o foco é o oposto: a proporção entre as camadas.

Como equilibrar na prática

Esqueça percentuais decorados. Use estas heurísticas:

Empurre a verificação para baixo até doer. Se a regra cabe num unitário, não escreva um e2e para ela. Reserve e2e para os 5 a 10 fluxos críticos de negócio (login, checkout, fluxo de pagamento) — o "caminho feliz" do dinheiro.

Trate análise estática como camada de teste. Adotar TypeScript estrito, ESLint e schema validation elimina bugs inteiros antes de qualquer teste rodar. É o degrau mais barato.

// Em vez de um teste unitário verificando que "id" não é undefined,
// o tipo já garante isso em tempo de compilação:
function getUser(id: string): User { /* ... */ }
getUser(undefined); // erro de compilação — bug pego de graça

Meça o que dói, não a contagem. Métricas úteis: tempo total da suíte, taxa de flakiness (testes que falham sem mudança de código) e tempo médio para descobrir a causa de uma falha. Cobertura de 100% com suíte instável é pior que 70% confiável.

Quarentene testes flaky em vez de re-rodar. Um e2e que precisa de retry três vezes não dá confiança — dá ruído. Isole-o, conserte ou apague.

Sintoma                          → Provável desequilíbrio
Suíte lenta + flaky              → cone de sorvete (e2e demais)
Refactor quebra 50 testes        → unitários acoplados a implementação
Bug de integração escapou        → meio (integração) anêmico

Perguntas frequentes

A pirâmide de testes está ultrapassada?

Não como conceito, sim como dogma de percentuais. A intuição econômica — testes mais altos são mais lentos e frágeis — continua válida em qualquer stack. O que envelheceu foi a proporção rígida: arquiteturas modernas justificam uma camada de integração mais gorda do que a pirâmide clássica sugere. Use-a como bússola, não como mapa exato.

Qual a diferença entre testing pyramid e testing trophy?

A pirâmide coloca os unitários como base larga. O trophy coloca análise estática na base, integração como a maior camada, e reduz unitário e e2e. O trophy nasceu no contexto de front-end moderno, onde testar componentes isolados com muitos mocks dá pouca confiança. Para back-end com lógica de negócio densa, a pirâmide clássica ainda costuma servir melhor.

O que é o anti-padrão do cone de sorvete?

É a pirâmide invertida: muito teste manual e e2e no topo, pouco unitário na base. Resultado típico: suíte lenta, frágil e cara de manter, com feedback que chega tarde demais no ciclo. É o problema que a pirâmide existe para evitar.

Quantos testes e2e devo ter?

Poucos e deliberados. Cubra os fluxos onde uma falha custa dinheiro ou reputação — autenticação, pagamento, cadastro crítico. Tudo que puder ser verificado mais embaixo (regra de negócio, validação, formatação) deve sair do e2e. Se a contagem de e2e cresce sem parar, provavelmente há lógica que deveria estar coberta por unitário ou integração.

O que levar deste guia

A pirâmide de testes não é uma lei física — é um modelo mental sobre o trade-off entre custo, velocidade e confiança. Esse trade-off não mudou: testes no topo continuam lentos e frágeis. O que mudou foi o contexto, e ele empurrou peso para a camada de integração e para a análise estática. Use o desenho que você quiser — pirâmide, trophy, honeycomb — desde que o princípio sobreviva: cubra cada risco na camada mais barata que ainda lhe dá confiança, e desconfie de qualquer suíte que seja lenta, instável e mesmo assim deixa bugs passarem.