Skip to content

Instantly share code, notes, and snippets.

@zec4o
Last active May 6, 2024 17:09
Show Gist options
  • Save zec4o/f4a600fafa50003e315fa3fcfd9c1e4a to your computer and use it in GitHub Desktop.
Save zec4o/f4a600fafa50003e315fa3fcfd9c1e4a to your computer and use it in GitHub Desktop.
Testes Automatizados de API com Postman

Testes Automatizados de API Rest com Postman 🚀🧑🏼‍🚀

Aqui você vai encontrar além de uma introdução sobre requisições no Postman, como testá-las de maneira automatizada.

Referências 📖

Lista das principais fontes de estudos do que vou passar aqui:

O que são requisições HTTP, na prática? 🤓

Na prática, requisições HTTP são chamadas feitas pelo cliente ao servidor e que, dependendo do método, esperam uma resposta.

Os métodos (ou verbos, como são comumente chamados) mais utilizados são:

  • GET - O método GET deve retornar os dados do endpoint ao qual foi feito a requisição.
  • PUT - O método PUT tem como objetivo alterar/editar, de maneira a sobrescrever os dados do endpoint da requisição.
  • PATCH - Diferente do método PUT, o PATCH altera somente os campos especificados no corpo da requisição, sem sobrescrever totalmente o endpoint.
  • POST - O método POST cria um novo recurso no servidor, nesse método, o corpo da requisição irá carregar os dados que serão transmitidos para o endpoint.
  • DELETE - O método DELETE, como o próprio nome já diz, remove um recurso específico.

Com essas informações, já podemos começar nossa jornada na WEB por baixo dos panos!

O que vamos usar? 😁💻

Para os nossos exemplos, estarei utilizando, além da ferramenta Postman, a fake API JSONPlaceholder.

Essa API possui os seguintes endpoints:

  • /posts - 100 publicaçöes
  • /comments - 500 comentários
  • /albums - 100 albuns
  • /photos - 5000 fotos
  • /todos - 200 todos
  • /users - 10 usuários

Vamos à prática!

Organizando as suas requisições no Postman 💻🧑🏼‍🚀

Em termos de organização, gosto de seguir o seguinte "breadcrumb": Workspace > Coleção > Requisição

  • No nosso caso, criei o Workspace "API Testing - JSONPlaceholder":

    creating a postman workspace

  • Como forma de organizar a visualização, criei coleções referentes à cada endpoint da API:

    creating a postman collection

  • Por fim, criei a requisição dentro da coleção referente ao endpoint que quero fazer a chamada.

    creating a postman request

Criando suas primeiras requisições no Postman:

Neste tópico, realizaremos todas as mais comuns requisições no endpoint /posts e analisaremos as suas respostas.

GET em /posts ✅

  • Para realizar uma requisição GET em /posts, basta inserir o link da API com o endpoint /posts e selecionar o método GET.

    GET /posts

  • Nesta requisição, conseguimos notar que o GET em /posts nos retorna uma estrutura com várias publicações, essas publicações contém em suas respectivas estruturas os seguintes atributos:

{
"userId" -> id do usuário que criou a publicação.
"id" -> id da publicação.
"title" -> título da publicação.
"body" -> corpo/texto da publicação.
} 

POST em /posts ✅

  • Para realizar uma requisição POST em /posts, basta inserir o link da API com o endpoint /posts, selecionar o método POST e passar o corpo da requisição. Note que não foi passado o id da publicação, uma vez que neste caso, a API assimila a nova publicação ao próximo Id não cadastrado, entretanto, há a possibilidade de passar quaisquer "id" no corpo da requisição, desde que o mesmo já não tenha sido assimilado anteriormente.

    POST /posts

  • No corpo da resposta, é possível notar os dados da publicação que foram passados na requisição e o id da publicação que foi assimilado pela API.

GET em /posts/{id} ✅

  • Muito parecido com o GET feito no endpoint_ /posts_, o GET em /posts/{id} deve nos retornar somente os dados da publicação referente ao id passado no endpoint.

    GET /posts/{id}

  • Nota-se que no corpo da resposta, temos apenas a estrutura da publicação referente ao id que foi passado.

PUT em /posts/{id} ✅

  • Para realizar a requisição PUT no endpoint /post/{id}, deve-se passar no corpo da request todos os dados que farão o "update" do id referido. Esses dados irão sobrepor o que existe atualmente no endpoint.

    PUT /post/{id}

  • Note que levando em consideração o exemplo que fizemos de requisição GET em /posts/1 podemos notar a diferença do conteúdo do endpoint /posts/1 antes e depois do PUT.

  • Neste caso, nota-se que o corpo da resposta é preenchido somente com os dados passados no corpo da requisição do método PUT (além do "id" que é assimilado automaticamente pela api, isso porque a URL já está passando o "id" como um parâmetro).

Antes

{
    "userId": 1,
    "id": 1,
    "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
    "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
}

Depois

{
    "title": "meu título",
    "id": 1,
}

PATCH em /posts/{id} ✅

  • Para realizar a requisição PATCH no endpoint /post/{id}, deve-se passar no corpo somente os campos que serão alterados na estrutura do id referido. Esses dados irão sobrepor somente os campos que foram passados no corpo da requisição, diferente do PUT.

    PATCH /posts/{id}

  • Também levando em consideração o exemplo que fizemos de requisição GET em /posts/1 podemos notar a diferença do conteúdo do endpoint /posts/1 antes e depois do PATCH: No nosso caso, como somente "title" foi passado no corpo da requisição, somente ele foi alterado na estrutura.

Antes

{
    "userId": 1,
    "id": 1,
    "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
    "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
}

Depois

{
    "userId": 1,
    "id": 1,
    "title": "meu novo título",
    "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
}

DELETE em /posts/{id} ✅

  • É simples realizar uma requisição de DELETE no Postman, basta selecionar o método e, neste caso, passar o parâmetro do "id" no endpoint. O corpo da resposta vazio

    DELETE /posts/{id}

  • Com o status de 200, é perceptível que a requisição de DELETE teve sucesso, desta forma, pode-se notar que não há corpo de resposta.

Para que servem as variáveis de ambiente no Postman e como criá-las

Agora que já sabemos como fazer requisições no Postman, vamos avançar mais um pouco e entender como as varíaveis de ambiente podem nos ajudar no que tange a automatização dos testes de API.

  • No nosso caso, as variáveis de ambientes serão de extrema importância para evitar a repetição e re-trabalho nos testes, além de claro, tornar a visualização menos complexa.

Criando nossa primeira variável de ambiente

Para isso, é necessário que seja criado o ambiente que comportará todas as variáveis criadas.

  • PASSO A PASSO PARA CRIAR AMBIENTE E VARIÁVEL MANUALMENTE:

    createenvironment

Atualizando uma variável de ambiente com base na response de uma requisição 🌐

Para atualizar uma variável de ambiente assimilando determinado conteúdo do corpo da resposta da requisição, é primeiro interessante saber que os testes no Postman, que podem ser feitos através do JavaScript embutido no software, só irão ser executados após a requisição ter sido concluída. Desta forma, vamos à prática!

Na aba "Tests" da requisição, deve ser passado o seguinte código:

var **variável declarada no teste que fará análise do JSON** = JSON.parse(responseBody)
pm.environment.set("variável de ambiente pré criada", **variavel que fará a análise do JSON**["variável que vem no corpo da requisição"]);
  • "var" -> irá declarar uma variável no teste da requisição.
  • "JSON.parse(responseBody)" -> fará a análise do JSON presente no response body da requisição.
  • "pm.environment.set" -> serve para setar o conteúdo da variável de ambiente dentro do ambiente atual selecionado.

Utilizando como exemplo a requisição de POST no endpoint /posts, gostaríamos de criar uma variável que assimilasse o "id" da publicação que será criada. Sendo assim, devo antes de tudo, criar uma variável de ambiente para assimilar o valor que será recebido no corpo da resposta. No nosso caso esta variável de ambiente será "id_da_publicacao".

Desta forma, nosso código na aba tests ficaria assim:

var jsonData = JSON.parse(responseBody)
pm.environment.set("id_da_publicacao", jsonData["id"]);

post+variable

Isso pode ser utilizado para diversos fins, como: Associar um token de autorização de uma requisição de cadastro à outras requisições que necessitam dele, por exemplo. Em testes, pode ser feito um POST seguido de um DELETE /endpoint/{id} pelo "id" que foi pego na requisição do POST. São inúmeras formas de utilização, vai da sua necessidade e criatividade!

Com isso, como fazer testes de API com validações no Postman? 🤷🏼‍♂️

O desenvolvimento de scripts de test no Postman são feitos de uma maneira bem simples, utilizando apenas a sintaxe de validações da Chai Assertion Library presente na estrutura dessa ferramenta, eles podem ir desde validações de status code até multiplas validações de cookies, response time, conteúdo de headers e entre outras.

Teste de validação de status code

O teste de validação pode ser feito utilizando a seguinte sintaxe:

 pm.test("nome do teste", function () {
 pm.response.to.have.status(status desejado);
});

test200ok

Repare que, tendo um status que valida o status code, se ele for igual o esperado o resultado é positivo para o teste. ✅

Testes de resposta da requisição ✅

  • Não muito diferente, os testes do response body, validam todo conteúdo que é recebido no corpo da resposta, com diversos "asserts" que são contemplados pela "Chai Assertion Library", então quando se tratam de validações, o céu é o limite!

Vários testes realizados em uma única requisição e que ficarão salvos para sempre que a requisição for feita:

    //validações do status code
      //Teste de validação de status code
pm.test("Status code é 200", function () {
pm.response.to.have.status(200);
});

      //Teste de resposta em texto do status code
pm.test("O nome do status code tem o texto: OK", () => {
pm.response.to.have.status("OK");
});

  //validações dos cabeçalhos da requisição
      //Teste para verificar a existência de um cabeçalho.
pm.test("Content-type está presente nos cabeçalhos", () => {
pm.response.to.have.header("Content-Type");
});

  //Validação de desempenho
      //teste de tempo de resposta
pm.test("O tempo de resposta é menor que 150ms", () => {
pm.expect(pm.response.responseTime).to.be.below(150);
});



//validações do corpo da resposta
pm.test("O response da requisição foi validado.", () => {
//criação de constante para fazer o parse do JSON
  const respostaDoJson = pm.response.json();
//teste que valida o conteúdo de uma variável
  pm.expect(respostaDoJson.userId).to.eql(1);
//teste que valida o tipo de uma variável
  pm.expect(respostaDoJson.userId).to.be.a("number");
  pm.expect(respostaDoJson.id).to.eql(1);
  pm.expect(respostaDoJson.id).to.be.a("number");
  pm.expect(respostaDoJson.title).to.be.a("string");
  pm.expect(respostaDoJson.title).to.eql("sunt aut facere repellat provident occaecati excepturi optio reprehenderit");
//teste que valida a quantidade de caracteres no conteúdo de uma variável
  pm.expect(respostaDoJson.title).to.have.lengthOf(74);
});
  • O resultado destes testes utilizando o método GET no endpoint /posts/1 da API que estamos utilizando foi o seguinte:

image Repare aqui que, por ter um tempo de resposta maior que o esperado no nosso script, o teste não passou!

Para finalizar, como rodamos todas as requisições e seus respectivos testes automaticamente?

  • Acessando a pasta principal da coleção, é possível notar o botão "run collection", que ao ser clicado começará a fazer as requisições na ordem de organização das pastas. Assim:

finalgif

Como um extra, explico a funcionalidade de Monitores no Postman. 🖥️✅

Além de tudo que foi passado aqui, criar um monitor para a sua coleção torna possível:

  • Estabelecer um timer para rodar todas as requisições automaticamente de X em X horas/dias/semanas
  • Receber e-mails automaticamente a cada erro/falha nos testes.
  • Estabelecer delays entre requisições.
  • Escolher região dos servidores do Postman onde os testes serão feitos.
  • Retestar automáticamente X vezes se um teste falhar.
  • Criar um tempo máximo para timeout das requisições.

monitor tests

FIM!

Muito obrigado pessoal! 🙏🙏

Tendo qualquer dúvida/feedback podem entrar em contato comigo através do meu Github ou Linkedin.

@thiagomeneguzzi
Copy link

Simplesmente sensacional! Vou aproveitar pra usar como guia para meus testes!

@clysrosa
Copy link

Conteúdo excelente, estava precisando muito e só achei aqui
Parabéns!!!

@adrianoo902
Copy link

Sensacional

@mirlisboa
Copy link

Excelente tutorial! Meus Parabéns!

@SergioManica
Copy link

Excelente tutorial, esclareceu muito bem!

@Rodrigo-Tozatti
Copy link

Ótimo material... obrigado!!

@rodrigokudaka
Copy link

Muito objetivo, parabéns

@fernandodomingosbezerra

Conteúdo Massa!!!

@Royal-Spymaster
Copy link

Muito obrigado cara, excelente! Você tem algo parecido usando Jmeter?

@zec4o
Copy link
Author

zec4o commented Mar 5, 2024

@Royal-Spymaster, infelizmente ainda não, amigo!

@Tgentil
Copy link

Tgentil commented May 6, 2024

Muito útil, @zec4o obrigado pelo seu trabalho! 👏🏼

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment