Um breve resumo sobre Pirâmide de testes
A pirâmide de testes é uma representação visual que simplifica os diversos
tipos de testes, seus níveis, velocidade de implementação e complexidade.
Essa representação é valiosa para entender o custo de implementação e
manutenção de cada tipo de teste, além de nos orientar sobre qual nível de
teste priorizar e por quê.
• Base: Testes de Unidade
• Meio: Testes de Integração
• Topo: Testes Ponta a Ponta (E2E, UI ou Testes de Interface)
Imagem 01
Cada nível de teste tem seus próprios objetivos específicos e foco de teste,
seja manualmente ou por meio de automação.
Agora, vamos examinar mais detalhadamente cada um desses níveis.
Base da pirâmide de testes: Testes de Unidade
Na base da pirâmide de testes estão os Testes de Unidade.
Também conhecidos como testes unitários, esses testes são realizados na menor parte testável de uma aplicação, independentemente de sua interação com outras partes do código.
Em um contexto de programação orientada a objetos, uma unidade pode ser classificada como um método público disponível em uma determinada classe.
Devido ao foco em testar os componentes mais granulares do código de forma isolada, os testes unitários tendem a ser muito pequenos e rápidos de criar e executar.
Essa abordagem permite identificar com precisão o local de uma falha caso um dos testes não passe.
Para viabilizar esse tipo de teste, é comum criar objetos falsos, também conhecidos como fakes, mocks, stubs e similares, que imitam o comportamento de objetos reais.
Dessa forma, não é necessário que outras unidades sejam reais para que o teste seja executado.
É possível criar esses objetos falsos para simular seu comportamento e testar a unidade de forma isolada.
Meio: Teste de integração
Apesar das vantagens anteriormente mencionadas dos testes de unidade,
eles por si só não são suficientes para garantir a qualidade adequada do nosso software.
É nesse ponto que entram os testes de integração.
Esses testes têm como objetivo avaliar um conjunto de unidades interagindo entre si.
Exemplos comuns de casos cobertos pelos testes de integração incluem a comunicação com o banco de dados, interações de interface, chamadas de APIs e microsserviços.
O motivo é que às vezes os testes unitários não são suficientes, pois podemos ter duas unidades funcionando conforme esperado individualmente.
No entanto, quando essas unidades precisam interagir, pode ocorrer um comportamento insatisfatório. Isso pode ser humoristicamente ilustrado pela situação mencionada anteriormente.Para evitar esses problemas, são implementados os testes de integração, que avaliam se as unidades funcionam de forma harmoniosa em conjunto.
Neste ponto, você pode se perguntar: "Se essas situações não são abordadas pelos testes de unidade e podem ser tratadas pelos testes de integração, por que não implementar apenas os testes de integração?"
Para responder a essa pergunta, podemos destacar alguns pontos:
- Os testes de integração, por avaliarem um conjunto de unidades, tendem a ser mais complexos de implementar do que os testes de unidade.
- Ao testar um bloco maior de código, caso ocorra uma falha, é necessário mais esforço para identificar e corrigir o problema.
- Os testes de integração geralmente têm uma execução mais lenta em comparação com os testes de unidade.
- Muitas vezes, os testes de integração exigem um ambiente completo para serem executados.
Topo: Testes de Ponta a Ponta (E2E)
Os testes de ponta a ponta (E2E) têm como principal objetivo simular o comportamento de um usuário final em nossa aplicação.
Eles reproduzem o ambiente real, iniciando um aplicativo ou abrindo o
navegador, navegando dentro da aplicação, clicando em botões e preenchendo formulários.
Ao final, validam se o comportamento observado corresponde ao esperado para aquela funcionalidade, garantindo o funcionamento de todo um fluxo dentro da aplicação.
Frequentemente, os testes E2E são usados como um parâmetro para avaliar a conformidade da aplicação com os critérios de aceitação.
O objetivo principal é demonstrar que a aplicação está operando conforme o esperado, em vez de identificar possíveis defeitos.
No entanto, assim como os testes de integração, os testes E2E são mais complexos e consomem mais tempo para execução. Portanto, é importante fazer uma seleção criteriosa dos cenários que serão cobertos por esses testes, priorizando os casos mais relevantes e estratégicos dentro do produto.
Por exemplo, é vantajoso e estratégico cobrir um fluxo de conversão, pois falhas nesse processo podem ter um impacto significativo nos objetivos do usuário.
Além disso, essa abordagem evita longos períodos de espera pela execução dos testes E2E ao realizar um deploy.
Analisando a pirâmide de testes e considerando as informações anteriores, podemos concluir que quanto mais próximo da base da pirâmide estivermos, mais simples será a implementação e mais rápida será a execução do teste.
Por outro lado, quanto mais próximo do topo da pirâmide estivermos, maior será a complexidade e, consequentemente, a lentidão na execução atente se a imagem 02.
Imagem 02
Fontes:
(Artigo) https://blog.onedaytesting.com.br/test-doubles/
(Artigo) https://blog.onedaytesting.com.br/piramide-de-teses/
(Curso Testes de unidade Masteclss Flutterrando) https://masterclass.flutterando.com.br/
Acesso 25/ Fev . 2024
