Pirâmide de testes

---

E aí ? Já ouviu falar ?

O conceito foi desenhado por Mike Cohn, a algum tempo atrás, mas até hoje, é sub utilizada nos times de desenvolvimento de software.

De forma simples:

A pirâmide traz a proposta de quebra de testes em três tipos, ou fases com o intuito de torna-los mais eficientes.

A maior parte dos times de desenvolvimento hoje pensam basicamente em testes de aceitação, buscando prever o que o usuário irá homologar, e dessa forma antecipar os problemas. Essa abordagem funciona, mas a que custo?

Pense bem, para fazer um teste de ponta a ponta, para verificar se o sistema realmente está fazendo o que o usuário quer, precisamos de muitos recursos envolvidos. Precisamos de um ambiente para o teste, com massa de dados para execução, precisamos normalmente de mais de um time envolvido.

Agora imagine você fazer toda essa mobilização e sua aplicação da um erro logo em um ponto de validação técnica, por um equivoco seu de programação. Um desperdício de tempo, dinheiro e recursos certo?

Esse é só um dos cenários que a pirâmide se propõe a resolver.

Vamos a ela:

Na primeira camada da pirâmide criamos os testes unitários, como o nome já diz, sua intenção deve ser de testar a menor unidade do sistema, o código. E para isso é bem importante que você teste a maior parte de problemas técnicos de implementação possíveis, buscando mitigar ao máximo a possibilidade de um erro de codificação.

A maior parte dos seus testes deveriam se concentrar nessa camada, por se tratarem de testes mais granulares.

Os testes unitários devem ser realizados com o conceito de mock, ou seja, dados simulados dentro do próprio programa.

Outra premissa para o funcionamento é que estes testes sejam automatizados, uma vez que eles devem ser executados com frequência.

Testes de integração, nessa camada, você deve buscar executar testes que garantam a integridade com outros componentes como tabelas, arquivos e filas, ou até mesmo um segundo microsserviço que ainda esteja dentro do seu domínio/contexto.

Nesse momento, a utilização de mock e virtualização são grandes aliados também, pois permitem que seus testes sejam automatizados de forma mais rápida e fácil.

Já os testes End to End devem buscar testar sua aplicação de ponta a ponta, com um resultado funcional observável, e sem a utilização de dados mockados. Neste momento a ideia é testar o sistema da forma mais próxima do ambiente produtivo.

Ok, agora que já sabemos o que é e para que serve a pirâmide de testes, podemos dar o próximo passo.

Exemplo de implementação:

Imagine um sistema de compra de automóveis. Nesse sistema, ao selecionar um veiculo para compra você verifica se o cliente possui crédito e efetiva a compra.

Imagine que nesse cenário você possui 3 equipes trabalhando.

Equipe A: Front End

Equipe B: Responsável pelo sistema de compra.

Equipe C: Responsável pela análise de crédito.

Neste cenário, os testes unitários por exemplo, deveriam se concentrar em um módulo apenas, imagine que somos o desenvolvedor do microsserviço de efetivar compra. Nesse cenário deveríamos testar apenas nosso serviço, sem bater na tabela e nem depender da entrada da requisição do serviço de analise de crédito.

Após esse teste podemos abrir para um teste integrado apenas com a nossa tabela, e com um mock de entrada, ou caso faça sentido testar apenas a caixa de responsabilidade da equipe B, mockando as entradas de dependência de outras equipes.

Na ultima camada de testes podemos ir para o teste de ponta a ponta, saindo do usuário, e passando por todos os módulos, validando o retorno ao usuário.

Se aplicada de maneira correta a pirâmide de testes traz diversos benefícios, aqui vão alguns :

| 1 Menor impacto no ambiente

Quando aplicamos a pirâmide de testes, diminuímos o impacto no ambiente como um todo. Imagine você que seu código foi escrito, porém você não realizou testes unitários. Caso você faça deploy do seu código em ambiente de homologação, e ele apresente algum erro de testes unitários, você causará impacto em todas as demais funções que dependem deste, atrasando os projetos dos demais integrantes do time.

Agora imagine que você fez os testes unitários, mas não realizou testes de integração. Quando você subir seu código para ambiente de homologação você corre um risco desnecessário de impactar varias equipes e diversos outros projetos.

Ou seja, o desperdício de tempo e esforço é exponencial. Sem contar o esforço que você vai desprender para arrumar o ambiente depois da “quebra”.

| 2 Menor necessidade de envolvimento de outras equipes

No desenho abaixo representei a necessidade de envolvimento de outros recursos para os testes. Se olharmos com cuidado, cada erro da camada de baixo da pirâmide que é encontrado mais a cima impacta diretamente na alocação de outras pessoas e equipes para o teste, se tornando um enorme desperdício.

Ou seja, um erro de testes unitários que você poderia ter pego sozinho em sua maquina local, se for pego em homologação, impacta diretamente na alocação e gasto desnecessário de tempo de outras pessoas. No exemplo simples que fiz você teria um gasto triplicado de esforço. Mas sabemos que no nosso dia a dia é muito maior do que isso.

| 3 Maior autonomia

Quando seus testes estão concentrados na camada de cima da pirâmide, você acaba por criar um acoplamento de alocação de recursos desnecessário. Caso um dos recursos não esteja disponível para acompanhar os testes você corre o risco de ficar com seu projeto parado, aguardando alocação.

Bom, esses são alguns dos benefícios que temos com a pirâmide de testes, e ai curtiu?

Compartilhe esse conteúdo com seus amigos e equipe.

Quer ver ainda mais dicas de tecnologia ? Me siga no insta @natanpf, vamos lá, juntos podemos aprender mais.

Até semana que vem.

Natan Pasquarelli Freitas