hoverfly

Hoverfly: virtualização de serviços para testes de integração

Recentemente abordei o problema que encontramos ao implementar testes de integração entre nossa aplicação e serviços de terceiros.

Hoverfly foi uma das ferramentas citadas que se propõem a auxiliar na resolução desse problema.

Segundo sua própria documentação: “Hoverfly é uma ferramenta leve, de simulação de API”, que possibilita simulações realísticas de serviços dos quais sua aplicação depende.

Alguns serviços de terceiros (não muitos) disponibilizam um tipo de ambiente “sandbox”, onde você pode rodar seus testes sem afetar os dados da sua conta de produção. Essa funcionalidade resolve o problema mencionado.

Ok, mas e para os outros serviços que não disponibilizam esse ambiente “sandbox”? O que fazer?

Hoverfly foi projetado para lhe dar os recursos necessários para criação do seu próprio sandbox de serviços de terceiros, um ambiente simulado para o desenvolvimento e testes de sua aplicação.

Ao contrário de mocs e stubs, outras abordagens para testes de integração, a simulação do ambiente lhe proporciona testar sua aplicação em cenários muito próximos à realidade que será encontrada em produção.

Você pode testar aspectos como:

  • Simulação de latência de rede;
  • Simulação de falhas do serviço integrado;
  • Simulação de limites no número requisições;
  • Criação de cenários específicos gerados pelas regras de negócio da sua aplicação.

Passemos agora para uma abordagem mais técnica do funcionamento da Hoverfly. Podemos utilizá-la de duas maneiras:

  • Como um servidor proxy;
  • Como um servidor web.

>>Leitura recomendada:
Por que fazer testes automatizados?

Utilizando como um servidor proxy

Nessa abordagem, a Hoverfly funcionará como um intermediário entre a sua aplicação e o serviço integrado, agindo exatamente como um proxy de rede. A figura abaixo ilustra como funciona a estrutura de requests nesse cenário:

Estrutura de requests para servidor proxy

Neste cenário é possível mensurar com certa precisão como a latência de rede pode afetar a comunicação entre sua aplicação e o serviço ao qual está integrada.

Mas, dessa forma, você ainda precisa se comunicar com o serviço de terceiro nos seus testes. Por isso é um cenário que, normalmente, é utilizado na fase de desenvolvimento da aplicação, ainda mais em testes de performance de funcionalidades, por exemplo.

Utilizando como um servidor web 

Utilizar Hoverfly como servidor web significa que a própria ferramenta simulará uma resposta que seria dada pelo serviço de terceiro. A imagem abaixo mostra a estrutura de requests nesse cenário:

Estrutura de requests para servidor web

Dessa forma podemos simular inúmeras possibilidades de testes de integração automatizados, como:

  • Simular a resposta dos diversos endpoints providos pelo serviço testado;
  • Testar possíveis falhas de resposta;
  • Simular limite do número de requisições.

Para criação desses diversos cenários, a Hoverfly pode ser configurada para rodar em 6 diferentes modos, com a restrição de que ela só roda um modo por vez:

  1. Modo de Captura;
  2. Modo de Simulação;
  3. Modo Espião;
  4. Modo de Sintetização;
  5. Modo de Modificação;
  6. Modo Diff.

Modo de Captura

Nesse modo, a Hoverfly roda como proxy e intercepta a comunicação entre sua aplicação e o serviço de terceiro e, de forma transparente, grava as requisições que saíram da aplicação e as respostas dadas pelo serviço de terceiro para cada uma dessas requisições.

Normalmente, esse modo é utilizado na etapa de construção e configuração da simulação do serviço que será utilizada quando ativamos a Hoverfly em modo de simulação. Funciona como uma etapa de captura de dados entre a nossa aplicação e o serviço em questão.

Como você já deve ter imaginado, não é possível rodar o modo de captura quando a Hoverfly está rodando como servidor web.

Modo de Simulação

No modo de simulação não haverá nenhum tráfego de dados entre sua aplicação e o serviço de terceiro.

A Hoverfly utilizará os dados de simulação, criados manualmente ou através do modo de captura, para responder às requisições da aplicação.

Normalmente, os testes automatizados de integração de respostas de endpoints rodam utilizando esse modo. 

Modo Espião

Nesse modo a resposta gravada nos dados de simulação são comparadas com a resposta real do serviço de terceiro.

Assim, é possível identificar quando as estrutura ou os dados de resposta do serviço integrado foram modificados.

Modo de Sintetização

Esse modo é utilizado para que você possa testar o cenário em que um middleware de tratamento de resposta da sua requisição é colocado entre sua aplicação e o serviço de terceiro.

Parece complicado, mas ele funciona quase da mesma forma que o modo de simulação, mas em vez de simular a resposta diretamente a partir dos dados de simulação, um bloco de código ou serviço intermediário é colocado para tratar tais dados e oferecer a resposta para a requisição.

Esse é um modo que, normalmente, é utilizado quando há muita dificuldade de criar os dados de simulação no modo de captura, devido a algum tipo de particularidade do serviço que está sendo integrado.

Nesses casos, você utiliza o middleware para fornecer as respostas de modo mais preciso e próximo a realidade.

Modo de Modificação

Muito parecido com o modo de captura. A diferença é que o modo de modificação não grava as requisições e respostas como no modo de captura.

Além disso, tanto a requisição quanto a resposta passam por um middleware antes de seguirem para o seu real destino.

Esse modo pode ser usado para modificar dados críticos para segurança antes do envio da real requisição ao serviço integrado e restaurá-lo no momento do tratamento da resposta.

Modo Diff

Se você precisa consultar detalhadamente as diferenças de respostas de um mesmo endpoint em momentos distintos, esse é o modo ideal.

Através da Hoverfly, você consegue consultar uma lista de diferenças entre a resposta atual da requisição enviada ao serviço integrado real e os dados de simulação gravados.

Para isso, a hoverfly armazena tanto a resposta simulada quanto a resposta real de uma requisição.

Hoverfly se aplica em qualquer contexto?

Como mencionado, a Hoverfly só pode rodar um modo por vez. Na decurso de criação da aplicação e da implementação de suas funcionalidades podemos utilizar os diversos modos para distintos propósitos, a depender do momento.

A intenção desse post é mostrar as possibilidades de uso da Hoverfly na resolução do problema levantado a respeito de testes de integração entre uma aplicação e serviços de terceiros acessados via API.

Boa parte das informações apresentadas podem ser encontradas na documentação oficial da ferramenta e uma gama de outras funcionalidades não foram abordadas.

A questão é: temos um problema comum no desenvolvimento de aplicações modernas e uma abordagem de solução para ele.

Mas no fim das contas, a avaliação dessa abordagem e o julgamento de sua real efetividade no contexto do seu projeto só podem ser traçados com precisão pela sua equipe técnica.

Compartilhar
You May Also Like