Mock WS

Estamos no final do ano e reparei que eu não publiquei nada no blog da devcave. Decidi que preciso voltar a escrever, e como estou destreinado vou começar trazendo uma ferramenta simples.

Cada vez mais temos a tendência de usar vários serviços inter-relacionados dentro de nossas aplicações, principalmente se estiver trabalhando com microservices. Quando queremos fazer aquele teste manual da nossa feature, precisamos subir um ou dois ou mais serviços para ter a operabilidade completa, e isso as vezes pode ser meio chato, nossa máquina não aguentar ou simplesmente não termos acesso à algum sistema.

Recentemente passei por um caso assim e resolvemos criar uma aplicação simples para processar as requisições e devolver respostas padrão. A medida que usamos, foram surgindo novas necessidades e resolvi fazer o post para compartilhar a iniciativa.

O MockWS é uma aplicação web que responde a qualquer chamada HTTP feita na porta que está escutando (por padrão 1899), com o intuito de mockar as chamadas num determinado serviço. Se não configurar mais nada, simplesmente responde um 200 com o body vazio.

Código fonte

Como sempre o código está no github e o README é bastante explicativo. Pode clonar ele:

> git clone https://github.com/iundarigun/mockws

Basicamente, contém um filtro que verifica as requisições e atua em função da configuração. Essa configuração fica no arquivo mockdefinitions.json dentro da pasta resources do código, e caso não encontrar uma configuração para a requisição, o resultado da chamada é padrão, status 200 e body vazio. O conteúdo é uma lista de configuração no seguinte formato json:

{
  "url": "/something",
  "file": "something.json",
  "verbs": ["GET"],
  "status": 200,
  "ratioError": 10,
  "delay": 2000
}

A continuação, vou descrever o que faz cada um:

• url: Contém a url correspondente à configuração. No exemplo, qualquer url que contenha “/something” vai ser corresponder nessa configuração (pex http://localhost:1899/something/123)
• file: Corresponde ao nome de arquivo que contém o body da resposta mockada. O arquivo por padrão está na pasta resources/json dentro do código fonte
• verbs: A lista de verbos que serão atendidos pela configuração. Podemos ter, para a mesma url, duas configurações diferentes, uma para o GET e outra para POST e PUT, por exemplo.
• status: Código HTTP de resposta. As vezes podemos querer simular uma resposta 201 ou 204, não só 200.
• ratioError: Caso estiver informado, usamos esse campo para fornecer respostas aleatórias de erro. O valor pode estar entre 0 e 100, e corresponde à porcentagem de chances de devolver um erro 500 (internal server error).
• delay: Caso estiver informado, antes de devolver a resposta, a aplicação simulará um delay na resposta. O valor é expressado em milissegundos.

O conteúdo do arquivo que faz referência no atributo file, deve ser no formato json.

Toda requisição é logada para permitir verificar as informações que chegaram no mock:

Como rodar com docker

Mas se o mock já está pronto, porque precisamos do código? Realmente, não precisamos, pois já existe uma imagem gerada com o projeto. Para rodar em docker, precisamos do seguinte:

• Pasta local com o arquivo mockdefinitions.json (por exemplo, ~/mockws)
• Dentro desta pasta, colocamos uma pasta json com os arquivos de body.
• E rodamos o comando docker para iniciar o contêiner:

> docker run -v ~/mockws:/home/config -d --name local-mock -p 1899:1899 iundarigun/mock-ws

A url começará a responder com o mock!

nota: O arquivo mockdefinitions.json é lido no inicio da aplicação, então para adicionar ou tirar uma configuração é necessário parar e iniciar o contêiner de novo. Se queremos mudar o body de retorno, é possível alterar os arquivos da pasta json e refletir as mudanças sem necessidade de reiniciar.

Bom, é isso. Qualquer dúvida, reclamação ou sugestão, estou à disposição!