Quando falamos de serviços de terceiros, os testes de integração consistem em validar a comunicação entre a nossa aplicação e estes serviços.
Hoje, arquitetar um software distribuindo-o em serviços (ou mais drasticamente em microsserviços) quase sempre é a escolha número um para o começo de novos projetos.
E são diversas as causas que podem ser levantadas como argumento:
- Distribuição de responsabilidades a respeito das regras de negócio;
- Agilidade de desenvolvimento e independência entre equipes;
- Ganhos de escalabilidade e etc.
Esse caminho nos leva invariavelmente a um problema.
Com a distribuição de serviços na arquitetura de uma aplicação, a comunicação entre eles passa a ser um item de suma importância para garantir o bom funcionamento do sistema.
Passamos a buscar então maneiras de garantir um nível alto de estabilidade na integração entre os serviços da nossa aplicação.
Vamos mais fundo ainda.
E quando estamos utilizando serviços de terceiros para compor nossa aplicação?
Como conduzir os testes de integração de maneira eficiente?
Este artigo busca explorar os problemas que surgem com a integração de serviços de terceiros e as maneiras com que são conduzidos os testes de integração nesse cenário.
Por fim, é apresentado uma lista de ferramentas disponíveis no mercado que podem nos auxiliar a vencer esse desafio.
>>Leitura recomendada:
As maiores vantagens de testes automatizados
Testes de Integração em serviços de terceiros
O conceito primordial a respeito de testes de integração é que diferentes unidades código em um determinado domínio, quando agrupadas e combinadas, devem produzir o resultado esperado.
Entretanto, os testes de integração ficam uma camada acima dos testes de unidade.
Mas em princípio, estes testes seriam feitos entre diferentes serviços do mesmo software.
Quando tratamos da integração entre serviços de terceiros, esse problema ganha um nível a mais de complexidade.
As unidades nesse contexto, são diferentes softwares responsáveis por domínios de negócio distintos que se comunicam através de suas APIs.
Os testes de integração nesse cenário precisam englobar e responder por questões até então inexistentes como:
- Como garantir que a API do serviço que consumo estará disponível na hora que meus testes rodarem?
- É preciso efetuar hits na API de produção do meu serviço terceiro para executar meus testes ou essa API disponibiliza algum tipo de sandbox?
- Preciso tomar cuidado para não atingir o limite de requisições que tenho sob contrato com essa API?
Hoje, de maneira macro, existem 3 caminhos que podemos seguir para lidar com estas questões.
Os testes de integrações podem ser executados utilizando:
- Requisição comum ao serviço de terceiro
- Stubs ou mocks da resposta do serviço de terceiro
- Um serviço virtual
Requisição comum ao serviço de terceiro
Nos testes de integração, são enviadas requisições comuns para a API do serviço que se pretende testar.
Mas isso requer que tenhamos algumas coisas em mente.
A primeira delas é que, como qualquer aplicação na web, o serviço testado pode estar indisponível no momento do teste, o que vai disparar uma falha no teste.
Se sua equipe utilizar conceitos de CI/CD no desenvolvimento e entrega da aplicação, pode ser que seu processo quebre, por um simples lapso de comunicação temporário com a API externa.
Executar requisições de consulta não afetará seus dados junto ao serviço de terceiro.
Mas fazer requisições com método POST por exemplo, pode gerar uma necessidade de apagar ou restaurar dados modificados no momento dos testes.
Essa abordagem também traz o risco de sobrecarregar o serviço de terceiro, o que pode causar a rejeição de requests, a depender do tipo de contrato que se tenha para essa comunicação.
Dito isso, apesar de ser a forma mais simples de testar a integração, é também a menos indicada para esse propósito.
Utilizando stubs ou mocks da resposta do serviço de terceiro
Stubs e mocks são conceitos parecidos e muitas vezes tratados como sinônimos.
Algumas fontes tratam stubs como dados hardcoded, ou seja, simulações fixas do que seria a resposta de um serviço em determinado cenário.
Nessa linha de raciocínio, mocks são simulações dos objetos ou respostas que podem ser construídos de maneira mais dinâmica para cada teste.
Se tivermos uma variedade muito grande de testes, escrever um stub para cada um pode ficar inviável.
Normalmente os mocks são construídos com ajuda de bibliotecas ou serviços.
O que faz com que estruturas de testes possam ser padronizadas e compartilhadas entre os desenvolvedores da equipe.
Mas utilizar supostos objetos de resposta “simulados” na integração com terceiros não identifica possíveis falhas ou anomalias na real comunicação com a API de terceiros num contexto próximo ao que se tem no ambiente de produção.
Como saber por exemplo, o quanto nossa aplicação é afetada pelo tempo de espera das respostas de requisições que fazemos a serviços de terceiros, antes dessa aplicação entrar em produção?
Teste de integração: um serviço virtual?
Algumas APIs já disponibilizam ambientes seguros para que o desenvolvimento de integrações seja conduzido com testes mais próximos do que será o ambiente real, com as duas aplicações se comunicando em produção.
Alguns chamam esses ambientes de desenvolvimento de sandbox.
Esse tipo de funcionalidade não é comum.
Por isso serviços que propõem a virtualização de outros serviços surgiram no mercado para preencher essa lacuna.
Um serviço virtual é usado para testes de requisições HTTP reais, como uma interface entre a aplicação em teste e o serviço terceiro.
Muitas vezes incluindo uma análise de tráfego e de sanidade das requisições e capturando reais respostas para futuras requisições similares.
Utilizar esse tipo de solução envolve um pouco mais de esforço de implementação é claro.
Então é muito importante analisar cada tipo de integração com terceiros mensurando seu impacto e sua relevância para o bom funcionamento da aplicação.
Serviços de mock e/ou virtualização de serviços disponíveis no mercado
Hoverfly é uma ferramenta de simulação de API.
Com ela é possível virtualizar um ou mais serviços, além de levantar métricas de latência de rede, exportar e compartilhar simulações de API com outros desenvolvedores.
Pode ser classificada como um ferramenta de simulação de dependência.
Também OpenSource, segundo sua própria documentação, o MounteBank cria uma série de “impostores” para agir de maneira on-demand, nos testes de integração com terceiros.
Com essa ferramenta é possível fazer stubs ou mesmo mocks de respostas esperadas para as requisições mapeadas.
Ferramenta que se propõe exclusivamente ao mock de serviços que possuem um contrato WSDL.
Ou seja, é usado para serviços que utilizam o protocolo SOAP em sua comunicação.
Classificada como um servidor para configuração de Mocks de serviços que rodam em HTTP.
Não oferece funcionalidades de virtualização de serviços com o conceito apresentado neste artigo.
Usada para Mock de APIs e virtualização de serviços.
Feita utilizando a WireMock como base, propõe uma entrega de valor parecida com a Hoverfly, mas com a entrega de funcionalidades extras que não são livres e de código aberto.
É um campo a ser explorado! A carreira do profissional de infraestrutura, o devops, pode ser uma opção!
Gostou do assunto? Aproveite e confira vagas para desenvolvedores com as melhores oportunidades para um desenvolvedor como você!
Espero que tenham gostado e até a próxima!
