Pirâmide de testes
Tudo que devemos aprender:
A pirâmide de testes, criada por Mike Cohn em seu livro Succeeding with Agile, é uma forma visual que nos permite definir os níveis de testes, e a quantidade que deve ter cada camada.
Além disso conseguimos visualizar os seus níveis de velocidades, complexidades e custos.
Para começar, podemos dividir a pirâmide, em três camadas, sendo: a base de testes unitários, o meio em testes de integração (service) e o topo em testes de ponta a ponta.
Aqui vai uma explicação sobre cada um.
Testes Unitários (Unit)
Os testes de unidades tem como objetivo verificar o funcionamento da menor unidade de código testável de uma aplicação, que também são independentes de colaboradores externos ligadas a unidade testada em questão. Essa unidade pode ser um método público dentro de uma classe (referência a Orientação a Objetos) como também pode ser um conjunto de classes e objetos interagindo entre si.
Para testar, evita-se usar acessos a base de dados, sistemas de arquivos ou disparar consultas de rede, ou qualquer recurso externo. Para realizar o teste, é configurado os dados de entrada(mocks) para avaliar se o valor retornado era o esperado.
Concluindo, os testes unitários são pequenos e rápidos, se referem a uma parte específica do código, são totalmente independentes, sem vínculos com outras partes da aplicação (utilização de mocks/stubs) e facilmente de se encontrar o problema, já que o teste cobre um escopo de unidade do código.
Testes de integração (Service)
Os testes unitários são simples e rápidos, mas muitas vezes eles não são suficientes para testar determinadas partes de códigos.
Por isso, os testes de integração, como o nome sugere, servem para determinar se as unidades de software desenvolvidas independentemente, funcionam corretamente quando estão conectadas umas às outras. O seu objetivo é testar se muitos módulos desenvolvidos separadamente funcionam juntos conforme o esperado.
Diferentes dos testes de unidades, para criar e executar os testes de integração é necessário dependências de componentes externos, alguns exemplos comuns para a cobertura desse tipo de teste são, a comunicação com banco de dados e a comunicação entre micro serviços.
*Para entender melhor a necessidade de testar duas unidades que interagem entre si, pesquise Two unit tests, no integration tests no Google Images.
Testes ponta a ponta (E2E)
Os testes ponta a ponta (E2E), buscam cobrir os casos principais de fluxos que o usuário faz, são testes que fazem a interação real de um usuário com a aplicação. Ou seja, ele vai clicar no botão, preencher formulários, abrir navegadores.
Esse teste é feito quando todas as dependências estiverem disponíveis, ou seja, em um ambiente com o frontend, apis, banco de dados conectados, utilizando o mesmo ambiente que o usuário final utilizará. O importante é testar realmente a aplicação de ponta a ponta, sem utilizar mocks.
Por serem mais complexos, nesses casos o tempo de desenvolvimento e de execução é muito grande. Por isso a quantidade dele em relação aos demais testes é muito menor.
Conclusão
Os testes de integração são importantes para cobrirem cenários que não podem ser cobertos por testes de ponta a ponta, e também para cobrirem cenários que o teste de unidade já cobriu muito bem. Seguindo essas informações, podemos perceber que, temos menos testes de integração que de unidade, e menos testes de ponta a ponta que de integração.
Ter bons testes, exige tempo e esforço e jamais será uma perda de tempo, pois garantem a regra de negócio do sistema fazendo com que a médio/longo prazo torne sua aplicação mais segura.
Os testes presentes na pirâmide, contém uma boa granulação entre eles, fazendo garantir um alto nível de cobertura para os cenários diversos da aplicação. Outro ponto muito positivo é que eles facilitam muito a manutenção.
Resumo dos testes
*Dados retirados de um artigo listado nas referências, sobre a média da quantidade de testes e o tempo que leva para rodar cada camada, na empresa Creditas em 2019.
