O que é a pirâmide de testes e ela ainda se sustenta para a forma como o software é construído hoje?

A pirâmide diz para ter muitos testes unitários rápidos, menos testes de integração e um número pequeno de testes end to end, porque custo e instabilidade sobem conforme você sobe enquanto a velocidade do feedback cai. Ela ainda se sustenta como modelo de custo. O que mudou é que, com serviços distribuídos, a camada do meio pesa mais, então testes de contrato e de integração muitas vezes merecem uma fatia maior do que o formato clássico sugere.

O formato vem da economia. Um teste unitário roda em milissegundos, falha por exatamente um motivo e quase nunca mente para você. Um teste end to end roda em minutos, depende de um navegador, de uma rede e de seis serviços, e quando ele fica vermelho você gasta vinte minutos descobrindo se o produto quebrou ou se o ambiente estava ruim. Então você quer muitos dos baratos e só o suficiente dos caros para provar que as peças estão ligadas entre si. Onde eu vi o formato clássico se dobrar foi em sistemas distribuídos. Se um serviço é basicamente orquestração, testá-lo pesadamente no nível unitário só testa os seus próprios mocks, então eu jogo peso para testes de integração e de contrato, o que dá um formato mais parecido com um diamante. Minha regra para posicionar um teste é perguntar qual é a menor coisa que poderia quebrar aquele comportamento, e testar nesse nível. Se o risco é um cálculo, unitário. Se o risco é dois serviços discordando sobre um payload, contrato. Eu guardo o end to end para um punhado de jornadas que nunca podem quebrar em silêncio.