Health Check com Postman

No primeiro texto da nossa série sobre ferramentas utilizadas para realizar testes de serviços, falamos sobre Pirâmide de Testes, Pipeline e Variação de Serviços Rest. Agora, seguiremos explorando testes de APIs, evoluindo no tema de testes divididos em Pipeline para esclarecer como utilizar o conceito de validação básica do status e performance do serviço.

O Health Check (checagem completa do ambiente) tem como objetivo validar se os endpoints da aplicação estão funcionando e respondendo adequadamente. Uma relação clássica pode ser feita é de pensar como um ping que mostra se a URL está respondendo e o tempo de resposta.

Vale lembrar que hoje, empresas que atuam como ‘as a service’ como Slack, Zendesk, Jira, entre outras, já disponibilizam para seus clientes páginas com os status e a disponibilidade dos seus serviços, as ‘Status Page’. Ou seja, a informação do estado das APIs não servindo apenas para o time de desenvolvimento ou de monitoramento, mas sendo entregue diretamente para os clientes que consomem os serviços.

Estratégia de testes de API

Efetuar testes para validar o status do serviço e o seu tempo de resposta é muito simples e rápido, além de gerar imediatos feedbacks. Por isso esse é o primeiro passo de uma estratégia de testes de API.

Pense no seguinte cenário: o (a) desenvolvedor (a) do seu time finaliza o desenvolvimento de um incremento de software; ao finalizar o deploy você se prepara para iniciar os testes da aplicação; ao chamar o serviço observa que está retornando status 404. O que você irá fazer? Dependendo das suas habilidades, talvez você tentará descobrir o porquê do serviço estar fora e subir a aplicação para que funcione, ou então chamar a pessoa que gerou o incremento para fazer com que o serviço opere corretamente.

Os testes de checagem (Health Check) da saúde da API, ajudam justamente nesse ponto. Com o retorno esperado do serviço, após o build dentro de um pipeline, o próprio serviço pode notificar o problema e as pessoas estarão aptas a tomar ação em relação a isso rapidamente, sem desperdício de tempo.

Como fazer

Como o objetivo de fazer uma validação do estado do serviço e rodar em um pipeline, indicamos a criação de uma coleção de testes separada dos testes funcionais, visto que elas podem rodar em estágios diferentes no seu CI ou CD. Além disso, como dito no post anterior, a proposta de dividir as rotas dos serviços também vale para estas validações.

Para criar testes, basta acessar a guia ‘Tests’ no Postman. Para facilitar o desenvolvimento de scripts você pode utilizar o recurso SNIPPETS, visto que a ferramenta utiliza bibliotecas em JavaScript,. Também indicamos fortemente esse recurso caso você ainda não esteja habituado à linguagem, pois nele você terá acesso a códigos prontos para serem utilizados.

Para fazer o Health Check vamos utilizar a opção ‘Status code: code is 200’. Ao selecionar a mesma, o Postman já disponibiliza o código necessário para validar se o status da resposta é 200. Executando a requisição do serviço, a ferramenta irá mostrar o resultado do teste na guia ‘Test Result’.

Com este script base, já é possível fazer variações de testes para outros códigos de resposta – observe que o texto ‘Status code is 200’ é o nome do teste. Em um pipeline, é essa informação que irá ficar como log no servidor, sendo assim é importante ter um nome claro do que está sendo testado para facilitar. Eu costumo utilizar o nome da requisição, complementando com o resultado esperado. Para pegar o nome da requisição basta utilizar o trecho de código ‘pm.info.requestName’.

Dependendo do projeto, as APIs têm requisitos de performance, sendo assim costumo incluir validações referentes ao tempo de resposta da requisição no Health Check, como é possível observar na imagem abaixo. Assim o tempo de resposta do incremento de código já pode ser validado em tempo de build. Vale salientar que, se tratando de performance de API, ferramentas de monitoramento em tempo de execução provavelmente irão trazer maiores benefícios.

Utilize o Console Log

Dependendo das skills da pessoa de QA, é natural treinar a habilidade de ler log, para entender o que a aplicação está fazendo. No entanto, saber entender logs há tempos já deve ser uma capacidade que faz parte do cotidiano de quem realiza testes.

Mensagens como: “Could not get any response”, “404 Not Found”, “Cannot GET …”, “Cannot POST …”, “Error while parsing JSON during the call”, “502 Bad Gateway”, “500 Internal Server Error” vão aparecer com frequência no seu console, logo é importante que você consiga interpretar as mensagens de erro e tomar as medidas para cada situação. Utilize o Postman Console log para identificar as operações que estão acontecendo.

Rodando os testes utilizando o Runner

Para rodar toda a collection dos testes, você pode selecionar a opção de ‘Collection Runner’ ou rodar via console. É importante dizer que o Postman não é uma ferramenta para testes de performance, assim como as vezes é utilizado: a plataforma apenas irá sequenciar requisições, o que não é o objetivo de um teste desse tipo.

Visualizando a tela ‘Collection Runner’, você poderá escolher entre rodar uma collection, uma pasta com requisições ou uma requisição em específico. Como explicado no primeiro post, cada pasta indica uma rota do serviço que está sendo validada – por isto sugerimos tal estrutura de projeto. No campo ‘Environment’, você pode utilizar as variáveis globais – o porquê deste recurso também foi explicado no primeiro post.

Acionando o botão ‘Run’, o Postman irá exibir a tela a seguir:

Nela você poderá observar o resultado dos testes que passaram e falharam. No caso dos testes que falham é possível observar o log do erro, facilitando assim o feedback das inconsistências encontradas.

Reforço que neste post abordamos uma das várias estratégias que podem ser utilizadas na ferramenta Postman. Para colocar em prática essas dicas é essencial adaptar ao seu contexto. No próximo post falaremos sobre testes funcionais utilizando variáveis randômicas, e também sobre como utilizar os testes gerados no Postman rodando em um pipeline.