No mundo de hoje, não dá para falarmos em inovação sem que esta palavra não venha acompanhada por </ testes >. Desde o momento em que tudo é planejado até sua implementação e evoluções incrementais, tudo é {testado, testado e testado} dia após dia aqui na Invillia.
Conheça de perto o Global Growth Framework™️ {aka GGF}:
nossa forma de inovar onde 82% dos times
possuem automação de testes em fluxos críticos_
Na Invillia, toda quarta-feira, ao meio dia, paramos uma hora para updates com dicas, how-tos, boas práticas e tendências selecionadas por nossos especialistas em Product, Agile, Back e Front, Mobile, Quality, Security e Data. Uma troca de experiências vital para quem adora o novo. E essencial para que a inovação nunca pare. Se a tecnologia está no sangue, a gente faz questão de deixá-la circulando cada vez mais_
TECH NA VEIA_ Automação de Testes de API com HTTParty
12 minutos de leitura
No artigo de hoje, compartilhamos os principais aprendizados da incrível edição sobre “Automação de Testes de API com HTTParty”, apresentada por Roberto Filho – Quality Analyst do time SaúdeiD – e nosso especialista no assunto.
Introdução
Para falar sobre Automação de Testes de API, nesta edição discorremos o conceito e a estrutura da API, além de sua interação e sobre o que ela retorna. Posteriormente, apresentamos o conceito de testes de contrato e sua importância, para, finalmente, falar sobre a automação com Ruby e HTTPParty e a criação de uma pipeline utilizando o GitHub Actions. A pipeline foi configurada para ser executada em dois momentos: quando for aberto um PR tendo como branch destino a master e uma outra execução agendada que definimos um cronjob para que seja executada a cada 1 hora de segunda a sexta feira. Por fim, nesta adicionamos a pipeline uma integração com o Slack para fazer o Report da execução dos testes via Slack.
- O que é uma API?
A sigla API representa as iniciais das três palavras em inglês “Application Programming Interface”, que numa tradução livre para o português significa “Interface de Programação de Aplicações”. Trata-se de um conjunto de rotinas e padrões estabelecidos e documentados por uma determinada aplicação A para que outras aplicações B, C, D etc. consigam utilizar as funcionalidades desta aplicação A, sem precisar conhecer detalhes da implementação do software.
- O que é JSON?
A API normalmente utiliza o Javascript Object Notation (JSON) para comunicação entre elas, que diz respeito a um padrão de troca de dados simples especificado por Douglas Crockford no ano 2000 (https://www.json.org/json-pt.html).
- Request
É possível “conversar” com a API enviando requisições para ela, que são as chamadas “requests” (requisição que o cliente faz para a API) compostas por URL (endereço pesquisado no navegador); por um método; por um header; e por um body.
- Response
É a resposta da API para o cliente composta por status code, header e body.
- Métodos HTTP
O request tem um método HTTP também conhecido como “Verbos HTTP” que são conjuntos de métodos de requisição responsáveis por indicar a ação que será executada para um dado recurso, por exemplo:
- GET – utilizado para a leitura de dados;
- POST – utilizado para a escrita de dados (por exemplo, quando utiliza a API para cadastros de usuários);
- PUT – utilizado para a atualização de dados já existentes;
- Delete – utilizado para exclusão;
- Outros – Ex: PATCH, Head, Options…
- O que é Header?
Traduzindo do português, é o cabeçalho da requisição HTTP que permite que o cliente e servidores transmitam informações adicionais como, por exemplo, o Content-Type, que indica o tipo de arquivo, o token de autenticação que é passado no Header etc.
- O que é Body?
É o local onde ficam armazenados os dados que são trocados entre cliente e servidor por meio dessas mensagens HTTP, também comumente chamado de Payload e, geralmente, é um JSON.
- Status Code
No response, a API retorna um Status Code, que se refere às mensagens que o servidor envia durante essas interações entre cliente e servidor. Ele possui algumas faixas de Status Code, como, por exemplo, a 100, 200, 300, 400 e 500. Podemos entender melhor olhando a imagem abaixo. Os status code mais comuns são o 200, 400, 404 e 500.
- O que são Testes de Contrato?
Um contrato é um acordo formalizado entre duas ou mais partes, e no mundo da computação não é diferente. Entre APIs, ele garante que, se todas as regras forem seguidas, a comunicação entre as partes ocorrerá como esperada. Dessa forma, é possível perceber a importância dos testes das regras, o que torna possível prever que, se as regras não estiverem sendo seguidas, quais problemas poderão ser encontrados.
- O que se pode validar nos Testes de Contrato?
Normalmente, deve-se validar regras que, dificilmente, serão alteradas com a evolução do produto como, por exemplo:
- Status Code, que é uma regra de comunicação (se na criação do usuário, ficar definido que a API deve retornar ao Status Code 201, se trata de regra de comunicação e que, dificilmente, será alterada durante a evolução do produto);
- Formato da resposta (se é JSON, XML etc. conforme se espera);
- Tipo de cada campo do response (string, inteiro, float, array etc.). Como boa prática, normalmente, não validamos o conteúdo do campo (principalmente se tratando de campos de texto), pois a aplicação pode sofrer alterações e o conteúdo do campo pode sofrer alterações.
- Ferramentas
- HTTParty – é uma Gem do Ruby utilizada para realizar requisições HTTP (POST, PUT, GET etc.). Documentação disponível em: http://github.com/jnunemaker/httparty;
- RSpec – uma Gem do Ruby que permite fazer asserções. Confira a documentação em: http://rspec.info/.
- Requisitos para rodar projeto de automação
- Ruby (qualquer versão)
- Editor de sua preferência
- Terminal também de sua preferência (cmder, windows, terminal, zsh…). Caso esteja utilizando Windows, recomendamos o uso do Windows Terminal.
- Repositório do projeto
http://github.com/RFilho01/testes-de-api-httparty
- Mãos na massa
Na prática, apresentamos a estrutura do projeto de automação, demonstrando a importância de fazer testes de API e a validação de seu contrato, que podem ser automatizados em contextos diferentes.
Passo a passo do exemplo com Ruby
Para rodar o projeto é necessário acessá-lo e executar na raiz o comando “bundle install” de modo a instalar todas as dependências. Funciona, basicamente, como um “npm install” em um projeto utilizando o NodeJS.
Inicialmente, estão disponíveis:
- Gitignore para ignorar arquivos sensíveis da nossa aplicação e evitar que sejam disponibilizados no repositório;
- Cucumber.Yaml, onde definimos preferências para a execução e report dos testes com o cucumber, além de definir os dois ambientes que utilizaremos nos testes (homologação e produção);
- O Gemfile, onde estão contidas todas as dependências de projeto e todas as Gems utilizadas;
- Gemfile.lock gerado pelo próprio bundle;
- Rakefile que é o arquivo de configuração do Rake
- README.md.
Neste caso, toda a estrutura do projeto como a geração de massa automática dentro da execução de cada cenário, escrita e boas práticas na construção da especificação com o Gherkin, além das estratégias, podem ser utilizadas em testes de contrato com Ruby e HTTParty.
Escrevendo Expects (Asserções)
Durante a codificação das asserções, podemos corroborar o que foi dito anteriormente: a importância de validar o tipo de cada campo retornando no payload de resposta e os riscos de validar o conteúdo de campos principalmente de texto.
Além da validação padrão (escrevendo um expect para cada asserção), há uma estratégia de validação dos campos de payloads de resposta com muitos campos, utilizando o json_schema.
Dúvida importante: É possível validar o JSON desta forma ou tem que ser um por um?
Neste caso, foi utilizada a validação campo a campo por se tratar de response pequeno, mas é uma estratégia bacana e importante utilizar o json_schema, principalmente, quando há muitos campos no retorno, dado que é contraproducente fazer isso na mão, campo por campo.
GitHub Actions
O Workflow criado dentro de uma pasta “.gitHub” é um padrão adotado pelo GitHub Actions. Dentro dela, criamos outros dois arquivos: o “contract-test-pr” para ser executado sempre que um pull request for aberto tendo como destino a branch master; e o “contract-test-scheduled” que é a estratégia de execução dos testes a cada 1 hora de segunda a sexta-feira.
Com isso, mostramos o passo a passo para criação do arquivo yaml da pipeline, estratégias para otimização da execução e cronjobs que podemos adicionar para execução da pipeline para executar os testes em momentos críticos onde precisamos validar a integridade da nossa aplicação.
Por fim, podemos integrar a pipeline no github actions com o slack para que, a cada execução, seja enviada uma mensagem para um canal dentro do workspace com o status da execução (sucesso ou falha) e as informações sobre a execução dos testes.
