Com as evoluções das ferramentas de testes, é possível escrever vários tipos de testes funcionais. Mas a finalidade de cada uma delas fica cada vez mais complicada de entender.
Neste artigo vou escrever um guia rápido sobre o que é, quando utilizar, características ideais e algumas observações para:
- Testes de unidade ou unitários
- Testes de integração
- Testes de contrato
- Testes de regressão visual
- Testes E2E
Sistema de exemplo#
Vamos utilizar o sistema de estoque como exemplo:
É um sistema de gestão de controle de estoque onde o processo de inventário é separado em um módulo à parte.
O usuário pode visualizar as informações do estoque e do inventário no browser ou no celular.
Teste unitário#
Objetivo
Verificar comportamentos específicos de um módulo de forma isolada
Onde utilizar
Exemplo para o Sistema de Estoque
- Comparando dois produtos, verificar qual vence antes.
Exemplo para o Módulo Inventário
- Verificar se as regras de contagem de um item de estoque funciona corretamente
Exemplo para Frontend WEB
- Verificar se é utilizado o componente correto para: estoque baixo, médio, alto
Exemplo para Frontend Mobile
- Verificar se é utilizado o componente correto quando é lido um endereço que não existe no sistema
Características ideias
- A execução de um teste deve levar milissegundos
- Quando falha o teste, o feedback do teste deve ser específico
Observação
É o tipo de teste que traz a maior quantidade de feedback rápido. Mas existem algumas dificuldades por ser o único teste puramente caixa branca.
Este tipo de teste depende diretamente da qualidade do código. Ou seja, quanto melhor a qualidade do código testado, mais simples de escrever o teste unitário.
Mas sabemos que a maioria dos projetos possuem um código de qualidade baixo, consequentemente um design que não favorece a testabilidade das unidades, criando um ambiente dentro da equipe que dificulta a escrita dos testes unitários.
Um outro desafio é que a compreensão sobre testes unitários é diferente no backend e no frontend. Por exemplo, existe o conceito de testes de widgets ou testes de componentes em frontend. Estes podem ser considerados como unitários ou não dependendo da definição da equipe.
Outro desafio no frontend é que deveria ter poucos testes unitários pois este módulo não é responsável pela regra de negócio. É responsável pela visualização dependendo da plataforma. No nosso exemplo, mobile ou web.
Mas muitas equipes escrevem tantas regras de negócio no frontend que surge uma necessidade real e desnecessária da escrita dos testes unitários no frontend.
Na minha honesta experiência, as pessoas que têm um domínio na escrita dos testes unitários, têm um domínio sobre o design e a arquitetura do código.
Teste de integração#
Objetivo
Testar as partes integradas que os testes unitários não conseguem verificar.
Onde utilizar
Exemplo Estoque+Banco de dados
- Verificar se o fluxo de separação de um produto funciona corretamente
Exemplo Inventário+Banco de dados
- Verificar se um fluxo de um inventário funciona corretamente
Características ideais
- Ambiente de teste bem configurado e replicável (No exemplo temos dois ambientes de teste de integração)
- Boa gestão automática para massa de dados
- A execução de um teste deve levar segundos
- Testes isolados para possibilitar execução paralela
Observação
É o tipo de teste que traz mais confiança sobre a funcionalidade do sistema, mas em compensação o custo para mantê-las é mais alto que um teste unitário por começar a depender de fatores externos.
Os fatores externos que podem fazer um teste falhar:
- Massa de dados incorreto
- Falta de atualização no banco de dados
- O teste falha somente quando executado em conjunto (falta de isolamento)
- Falta de configuração no banco de dados
Todas essas falhas são parte do ambiente de teste e não é um erro específico do comportamento do sistema. Essas falhas fazem a equipe começar a abandonar ou ignorar os testes de integração.
O ambiente de teste torna-se então um fator importante.
Existe também o abandono dos testes unitários por testes de integração. Isso ocorre quando a equipe tem dificuldade de escrever um bom teste unitário por falta de testabilidade no design criado pela própria equipe.
É importante escrever testes de integração, mas sempre em conjunto com testes unitários.
Testes de Contrato#
Objetivo
Garantir que o protocolo de comunicação entre os módulos sempre esteja correto. Ou seja, existe um contrato que os dois módulos devem cumprir.
Onde utilizar
Exemplo Estoque -> Frontend WEB e Mobile
- Para a tela de quantidade de estoque no endereço, deve enviar a informação no seguinte formato:
{
Nome: String,
Lote: String,
Validade: String,
Quantidade: Inteiro,
}
Exemplo Estoque-> Módulo Inventário
- Para a informação do produto, deve enviar a informação no seguinte formato:
{
Nome: String,
Lote: String,
Validade: String,
Quantidade: Inteiro,
}
Exemplo Inventário -> Frontend WEB e Mobile
- A consulta de contagem deve enviar a informação no seguinte formato:
{
Endereco: String,
idProduto: Inteiro,
responsavel: String,
idContagem: Inteiro
}
Características ideais
- O consumidor (Frontend e inventário) deve ser o mandante do contrato
- O provedor deve sempre cumprir o contrato gerado pelo consumidor
- O teste de contrato no lado do consumidor deve ser unitário
- O teste de contrato no lado do provedor deve ser integração
- A velocidade de execução deve estar de acordo com o tipo de teste
Observação
Teste de contrato surgiu como um tipo de teste para eliminar a dependência de ter dois módulos em execução.
A ideia é testar o consumidor e o provedor isoladamente a partir do contrato fornecido.
Exige um conhecimento bom sobre testes unitários e de integração para verificar se o contrato ainda é cumprido tanto no consumidor quanto no provedor.
Uma dificuldade que surge neste tipo de teste é quando existe um time responsável por cada módulo. Exige uma boa coordenação para que as duas equipes consigam desenvolver independentemente sem bloqueios.
Outra dificuldade é a curva de aprendizagem. Por ser um tipo de teste que surgiu recentemente, as boas práticas sobre testes de contrato ainda são poucos conhecidas.
Mas é um tipo de teste que é válido criar quando o seu sistema “conversa” com muitos módulos e fica custoso subir todos os módulos ao mesmo tempo.
Teste de Regressão Visual#
Objetivo
Verificar se a interface do usuário foi alterada quando comparada com um snapshot inicial válido.
Onde utilizar
Exemplo
Os exemplos são os snapshots das telas WEB ou Mobile escolhido pela equipe
Características ideais
- Ambiente de teste que não dependa de outros módulos
- Facilidade em criar Mocks de request e response
- Dados que são utilizadas na interface devem ser o mais próximo da realidade
- Verificar somente os fluxos mais utilizados em produção
Observação
Este tipo de teste é o mais importante no frontend pois foca na parte visual do sistema.
Quando temos um snapshot válido do sistema com todas as informações e botões aparecendo de forma correta, garantimos que bugs visuais não ocorram em ambiente de produção.
A dificuldade deste tipo de teste é a criação de ambiente com módulos falsos. O famoso mock.
Quando criamos mocks de módulo, criamos uma complexidade extra pois o mock sempre deve acompanhar a mudança do módulo que ele está simulando. É um trabalho extra.
Mas mock se torna importante pois não queremos que o texto das telas fique alterando toda hora.
Mas é possível eliminar este trabalho se tivermos o teste de contrato funcionando. Podemos gerar mocks a partir do contrato definido mas exige um esforço técnico incial.
Outro desafio é que este teste é caixa branca. Parece ser caixa preta pois focamos na parte visual mas ainda temos que interagir com as ações dos botões e entender os dados enviados no request e response.
E, novamente, quando o código não é de qualidade, a escrita de um teste de regressão se torna novamente complexa, dificultando a adoção deste tipo de teste.
Teste E2E#
Objetivo
Verificar o fluxo mais utilizado pelo usuário final ou o fluxo que gera lucro para a empresa.
Onde utilizar
Exemplo
- Verificar se a separação dos itens ocorre sem problemas, junto com o processo de inventário. (Neste caso, a separação dos itens é um processo muito frequente e utilizado pelo usuário. Se este processo travar, travamos o processo inteiro do cliente).
Características ideais
- Simular ou utilizar o ambiente de produção
- Possibilidade de realizar vários testes funcionais e não-funcionais no mesmo ambiente
- Ter poucos testes deste tipo
Observação
Testes E2E são os testes que ficam mais próximos da realidade do usuário final. Em compensação é o ambiente mais custoso de manter.
Existem situações onde este tipo de teste não é necessário. Tais situações ocorrem quando o projeto possui um conjunto confiável de testes unitários, integração e de contrato.
Mas quando este conjunto confiável de testes não existe, muitas equipes recorrem também para este tipo de teste mais custoso sem as vantagens oferecidas por ela.
A principal vantagem deste tipo de teste é a garantia de que você não vai gerar problemas críticos para o cliente no fluxo principal e a possibilidade de simular situações de bugs que só é reproduzível em um ambiente parecido ou igual a de produção.
É o tipo de teste que deve ser feito em conjunto com uma boa estratégia de testes.
Criar este tipo de teste sem uma estratégia que envolve custo, manutenção e vantagens oferecidas por ela, é uma receita pronta para falhar e ficar abandonado.
Conclusão
Essa é uma lista de tipos de teste automatizados que geram mais impacto positivo para um projeto.
Se você e sua equipe souberem qual o tipo de teste que deve ser utilizado e escreverem um teste de qualidade, os testes serão valorizados e a cultura de testes automatizados melhora naturalmente com o tempo.
Recomendo muito começar a escrever os testes pelo mais simples e depois ir para um nível acima de complexidade:
- Teste unitário ou de unidade: É o mais simples pois não precisa do ambiente de teste.
- Teste de integração: É parecido com unitário mas envolve ambiente de teste bem feito.
- Teste de contrato: Exige conhecimento sobre testes unitários e de integração.
- Teste de regressão visual: Exige um conhecimento diferente dos testes anteriores mas o conhecimento sobre ambiente de teste ajuda.
- Teste E2E: É o mais complicado e exige todos os conhecimentos anteriores. Precisa ter também o conhecimento o suficiente para decidir se vale a pena ou não começar a escrever testes E2E.
Comece com testes unitários e, aos poucos, avance para os mais complexos. Automatize o que for repetitivo (ex: E2E de fluxos-chave) para ganhar eficiência!
Você já escreveu quais tipos de teste? Tem algum interessante que não tem listado aqui?
Comenta ou vem falar comigo!
Se tiverem mais curiosidade sobre o assunto ou quiserem sugerir um tema que eu conheça, podem falar comigo ou enviar um comentário!
🥒🥒 Espero que tenham curtido e até o próximo artigo! 🥒🥒