Testes funcionais em APIs REST com a ferramenta Frisby.js — Parte 2
Dando continuidade a série de posts (se você perdeu a parte 1, clica no link e dá uma conferida!), vamos falar sobre requisições POST / PUT e sobre como usar os recursos de setup disponibilizados pelo Frisby.js.
Bora?
First things first!
Uma das principais diferenças entre requisições GET e POST/PUT é que o GET tem o objetivo de buscar informações no servidor e os critérios para a consulta são enviados na própria URL como parâmetros, enquanto que o POST/PUT além de algumas similaridades tem o objetivo de fazer alterações de informações no servidor e os parâmetros são passados dentro do corpo da requisição.
Como fica isso no Frisby.js?
Vamos criar um novo arquivo dentro da pasta __tests__, chamado post_put_test_spec.js.
Nas requisições POST e/ou PUT, dependendo da construção de sua API, devemos passar os dados no corpo da mesma. Este corpo é conhecido como body quando falamos de API.
No exemplo abaixo, iremos realizar uma requisição POST na API do Postman atribuindo a informação `foo1` com o valor `bar1` e esperamos que isso nos retorne o status 200 (OK para o HTTP).
Como você pôde notar, passamos a propriedade body como um parâmetro para que a requisição seja interpretada corretamente.
A implementação do método PUT se comporta de maneira similar. Segundo a própria documentação do Postman:
The HTTP PUT request method is similar to HTTP POST. It too is meant to transfer data to a server (and elicit a response). What data is returned depends on the implementation of the server.
Fonte: https://docs.postman-echo.com/
Com isso, podemos incrementar nosso teste para realizar uma requisição PUT de maneira muito próxima ao POST, conforme exemplo abaixo:
Mas e o setup?
O setup é um recurso que permite incluir e agrupar configurações relacionadas as requisições que serão executadas.
O Frisby.js entrega dois tipos diferentes de setup: Um local, que afeta apenas a requisição em questão, e um a nível global onde as configurações incluídas terão abrangência e efeito em cada teste a ser executado dentro do arquivo.
Vamos fazer uma pequena alteração nos testes e fazer a inclusão de um setup com o objetivo de informar explicitamente qual o Content-type das requisições.
Já pensou se fosse necessário incluir essas configurações em cada teste que deve ser executado? Daria uma grande dor de cabeça na manutenção dos testes.
Para isso usamos o setup global. Como essas configurações fazem parte de todas as requisições, podemos abstrair a implementação da seguinte forma:
No final de tudo, se executarmos novamente nossa stack devemos visualizar o seguinte cenário:
Próximos passos
Este é o nosso segundo artigo da série, mas já temos na manga mais dois conteúdos para as próximas duas semanas.
São esses aqui:
Parte 3: Testes aninhados (dependentes) e inspetores
Parte 4: Customizando relatórios de execução dos testes
Perdeu a parte 1? Clica no link abaixo e seja feliz :)
Parte 1: Introdução e requisições GET
Quer saber mais?
Queremos estreitar relações com as comunidades e profissionais de tecnologia que queiram trocar figurinhas.
Por enquanto, os comentários aqui do Medium são nosso canal de comunicação oficial. Deixa sua mensagem para que possamos interagir ou mande um e-mail para ecs_it@br.experian.com.
Temos várias vagas nas áreas de Negócios e TI! O que você acha de dar uma olhada lá? É só clicar nesse link.
Até breve…
Luiz Eduardo Martins e Jonathan Henkels — Serasa Consumidor
