A pirâmide de testes: qual teste pertence a qual camada

O que é

Segundo o verbete de Fowler em seu bliki, a pirâmide de testes ficou conhecida principalmente por Mike Cohn, que a descreveu em 2009 em «Succeeding with Agile». Ela organiza os testes automatizados em camadas: na base, muitos testes unitários, que verificam uma unidade isoladamente e em milissegundos; no meio, testes de integração, que incluem vizinhos reais, como banco de dados ou sistema de arquivos; no topo, poucos testes ponta a ponta, que exercitam o sistema inteiro por sua interface pública. Subindo, aumentam o custo e o tempo de execução; descendo, aumentam a precisão e a velocidade. Fowler chama a forma inversa, com uma cabeça grande de testes de interface e quase nenhuma base, de cone de sorvete («ice-cream cone»). O artigo «The Practical Test Pyramid», no mesmo site, percorre as camadas usando um microsserviço de exemplo.

Por que importa

Cada camada troca proximidade com a realidade por valor de diagnóstico. Um teste unitário que falha aponta a função; um teste ponta a ponta que falha aponta o sistema, e só então a busca começa. Suítes com testes lentos em excesso rodam raramente, ficam instáveis com mais frequência e acabam sendo ignoradas aos poucos. A pirâmide mantém o feedback rápido o bastante para que desenvolvedoras, desenvolvedores e agentes testem a cada pequena mudança.

Como aplicar

• Coloque a lógica em unidades que possam ser testadas sem infraestrutura (funções puras, classes com dependências injetadas) e teste-as exaustivamente na base, incluindo casos-limite e de erro.
• Verifique os pontos de contato, como consultas, handlers HTTP, serialização e filas, na camada do meio, contra dependências reais em contêineres, e não contra simulações do banco de dados.
• No nível ponta a ponta, cubra apenas os poucos fluxos cuja falha afeta o negócio (login, compra, exportação) e execute-os no branch de integração, em vez de a cada commit.
• Se um teste ponta a ponta falhar, reproduza o mesmo erro também com um teste de nível inferior, que o encontre mais rápido no futuro.
• Acompanhe o tempo de execução da base; se ele passar de alguns segundos, vale procurar testes de integração disfarçados de testes unitários.

Armadilhas

Testes unitários que substituem tudo por simulações (mocks) acabam testando as próprias simulações. Testes de integração com estado mutável compartilhado passam a depender da ordem de execução. A pirâmide descreve proporções, não quantidades fixas; um serviço pequeno pode ser achatado e, mesmo assim, bem testado. O próprio Fowler observa que a premissa de que «testes amplos são caros, lentos e frágeis» vale na maioria dos casos, mas nem sempre.