A pirâmide de testes: por que nem tudo deve ser E2E

A resposta curta é esta: nem tudo deve ser E2E porque uma suíte equilibrada tem muitos testes unitários rápidos, alguns de integração e pouquíssimos de ponta a ponta. Essa proporção, e nenhuma outra, é o que faz uma suíte rodar em segundos, falhar com precisão e merecer a sua confiança. Quando você a inverte, obtém o oposto: horas de espera e resultados em que ninguém acredita.

Quase toda equipe que sofre com seus testes tem o mesmo problema estrutural, mesmo sem saber. Não é que faltem testes. É que os têm nas proporções erradas. Construíram a pirâmide de cabeça para baixo.

01 · a formaO que a pirâmide diz e por que é uma pirâmide

A pirâmide de testes é uma ideia popularizada por Mike Cohn que a indústria adotou porque descreve bem uma tensão real. Na base ficam os testes unitários: muitos, pequenos, que verificam uma função ou uma classe em isolamento. No meio, os de integração: menos, que comprovam que duas ou mais peças conversam bem entre si (seu código e o banco de dados, seu serviço e uma API). No topo, os E2E (de ponta a ponta): pouquíssimos, que exercitam o sistema completo como um usuário faria, do clique até a resposta.

A forma não é decorativa. É uma pirâmide porque as proporções importam: muito do que é barato e rápido, pouco do que é caro e lento. A cada nível que você sobe, os testes ficam mais lentos de rodar, mais difíceis de escrever, mais frágeis diante de qualquer mudança e mais vagos quando falham. Um unitário que quebra aponta para a linha exata. Um E2E que quebra diz que "algo, em algum lugar, deu errado".

A cada nível que você sobe custa mais e diz menos.

02 · a casquinha de sorveteO antipadrão: quando a pirâmide se inverte

Agora vire a figura de cabeça para baixo. Base estreita de unitários, um pouco de integração, e no topo uma montanha larga de E2E. Isso tem nome: a casquinha de sorvete (ice cream cone). É o antipadrão mais comum e quase nunca é uma decisão consciente; chega-se lá por acumulação.

Acontece assim. A equipe está com pressa. Escrever um teste E2E "parece" mais completo: abre o navegador, clica, confere que a tela mostra o que deve. Parece cobrir tudo de uma só vez, então escrevem-se muitos e negligenciam-se os unitários. Por cima de tudo costuma haver uma camada de testes manuais feitos por pessoas, a mais lenta e cara de todas.

O resultado você sente na pele:

• A suíte leva horas. Cada E2E inicia o sistema inteiro. Centenas deles transformam a validação numa espera de café longo, não de café curto.
• Os testes são intermitentes (flaky). Falham e passam sem que você mude nada, por uma rede lenta, um tempo limite, um elemento que demorou a carregar. A intermitência é o veneno da confiança.
• Ninguém confia no vermelho. Quando metade das falhas é ruído, a equipe aprende a ignorar o vermelho. E uma suíte que se ignora não protege de nada.
• Quando algo falha, você não sabe onde. Um E2E quebrado abrange vinte componentes. Depurá-lo é uma caçada, não uma leitura.

03 · as proporçõesQuanto de cada coisa: uma regra de bolso

Não há uma tabela sagrada, mas há uma ordem de grandeza útil que muitas equipes usam como ponto de partida: cerca de 70 % unitários, 20 % integração e 10 % E2E. Não tome como lei; tome como bússola. Um componente muito visual talvez precise de mais E2E; uma biblioteca de cálculo precisa quase só de unitários. O que não muda é a hierarquia: a base sempre pesa mais que o topo.

A pergunta certa ao escrever um teste não é "qual nível uso?", mas "qual é o nível mais baixo que pode me dar essa confiança?". Se um bug pode ser caçado com um unitário, cace-o com um unitário. Reserve o E2E para o que só pode ser verificado de ponta a ponta: que as peças, juntas e num ambiente real, cumprem o fluxo crítico do usuário.

Pense nisso como um orçamento. Sua suíte gasta tempo de CI a cada execução, e esse tempo é dinheiro e, sobretudo, é velocidade da sua equipe. Cada minuto que uma pessoa espera por um resultado é um minuto sem implantar. Os unitários compram muita confiança por muito pouco tempo. Os E2E compram pouca confiança por muito tempo. Um bom QA administra esse orçamento com a mesma disciplina com que você administraria dinheiro: invista no barato e use o caro com critério.

Use o nível mais baixo que lhe dê a confiança que você busca. Nem um nível acima.

Corrigir a casquinha de sorvete não é jogar os E2E no lixo. É o contrário: é descer as validações ao nível mais barato possível e deixar no topo apenas o punhado de fluxos que de fato importam. A suíte emagrece onde deve e engorda onde convém. No dia em que seu CI volta a rodar em minutos e o vermelho volta a significar algo, você sabe que a pirâmide está de pé sobre sua base outra vez.

04 · o padrãoPor que isto também é uma decisão de qualidade, não só de velocidade

Pode parecer que tudo isto é sobre ir rápido. É sobre algo maior. A norma ISO/IEC 25010 define a qualidade do software em atributos como confiabilidade e manutenibilidade. Uma suíte equilibrada serve diretamente a ambos: é confiável porque seu vermelho é sinal e não ruído, e é manutenível porque quando algo quebra, leva você à causa em vez de a uma caçada.

O ISTQB, em seu corpo de conhecimento para testadores, insiste em que testar é uma atividade de gestão de risco, não de acumulação. Não se trata de ter mais testes, mas os testes que reduzem o risco que de fato preocupa você, ao menor custo. A pirâmide é, no fundo, essa ideia feita forma: coloque o esforço onde ele compra mais certeza por menos tempo.

Então, da próxima vez que alguém propuser "vamos cobrir isto com outro teste E2E", faça a pergunta de sempre: este é o nível mais baixo que nos dá a confiança que buscamos? Se a resposta for não, você tem um unitário esperando para ser escrito, e uma pirâmide que agradecerá por continuar de pé.