Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Joinfut Wiki Joinfut Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 6
    • Issues 6
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Joinfut
  • Joinfut WikiJoinfut Wiki
  • Wiki
  • Backend
  • postman_utilizacao

Last edited by Gabriel Fanto Stundner Sep 06, 2022
Page history

postman_utilizacao

Wiki normal



Wiki Backend




Utilizando o postman no projeto joinfut


Importando Requisições Existentes

  1. no topo a esquerda do postman tem a opção import, clique nele e ele abre uma página para fazer upload dos arquivos
  1. Importe a coleção(conjunto de requisições) e o ambiente(onde ficam as variáveis necessárias para as requisições) desejada do diretório Requisições
  1. No postman vai mostrar quais você está importanto e informações importantes
  1. Dentro de toda coleção de requisições tem dois diretórios:

    4.1) CRUD ficam todas as requisições base da entidade, todas devem estar funcionando

    4.2) VALIDATIONS ficam as validações dos objetos dentro da entidade.

  1. As requisições devem possuir as seguintes nomenclaturas:
<Tipo de Operação no banco> <Nome Entidade>

Deve seguir o padrão CRUD

  1. As validações o nome deve ser o que está sendo validado, onde deve possuir uma requisição para casa validação e objeto:
  1. O Ambiente (Enviroment) ficam as constantes utilizadas no projeto, onde cada conjunto de requisição terá o seu, mesmo que tenham somente a URL de teste
  • Sua localização fica a direita bem na ponta
  • Quando é testado, na hora que é criado um objeto da entidade, ele vai salvar o ID do objeto criado no banco e esse valor vai ser salvo no ambiente Global (globals), onde ficam as variáveis de utilização entre requisições

Testando as requisições

Tipos de Requisição
POST
GET By ID
PUT
GET ALL
DELETE
VALIDATIONS
Rodando todos os testes ao mesmo tempo
  • No estilo arquitetural REST, a manipulação dos recursos disponibilizados para o cliente é realizada através de métodos do protocolo HTTP.

POST

  • É utilizado para criar um novo registro no banco de dados.
  • Tipo de resultado: Status Code 201 – registro criado
  • Graças ao POST, podemos fazer uma operação chamada CREATE no banco de dados,é uma operação de insert que o Springboot faz por nós no Controller.
  • Nomenclatura dessa Requisição: Create <Nome do Model>
  1. Na aba Body no postman iremos colocar os dados que queremos salvar, dai quando cliado no botão Send ele vai enviar os dados para a API e terá como retorno o Status que retornou da API e um JSON no Response com os dados salvos
  1. Na aba Tests os testes são criados em Javascript e devem ser colocados em ordem, assim que o resultado da requisição for 201 ele vai salvar o ID do objeto em uma variável global

GET By ID

  • É utilizado para buscar um registro no banco de dados pelo ID passado na URL
  • Tipo de resultado: Status Code 200 OK
  • Graças ao GET, podemos fazer uma operação chamada READ no banco de dados
  • Nomenclatura dessa Requisição: Read <Nome do Model>
  1. Na URL da requisição chamamos a variável global que foi gerada com a requisição POST ou podemos criar a variável manualmente no Enviroment, mas somente se o conjunto de requisições não tem como conseguir esse id.
  1. Na aba Tests somente tem o teste que o GET deve retornar o código 200, mas podemos ter testes que também salvam um ID específico caso precise. O retorno da requisição é o objeto que demos o ID que está salvo no banco de dados

PUT

  • É utilizado para atualizar um registro no banco de dados pelo ID passado na URL.
  • Tipo de resultado: Status Code 200 OK
  • Graças ao PUT, podemos fazer uma operação chamada UPDATE no banco de dados.
  • Nomenclatura dessa Requisição: Update <Nome do Model>
  1. Na URL da requisição chamamos a variável global que foi gerada com a requisição POST ou podemos criar a variável manualmente no Enviroment, mas somente se o conjunto de requisições não tem como conseguir esse id.
  2. No Body da requisição colocamos quais dados queremos editar do objeto salvo no banco, eles devem ter os mesmos nomes dos objetos salvos, senão vai dar um erro
  1. No Response (resposta da API) vai mostar um JSON com os dados do objeto que foram salvos no banco, já mostrando a atualização dos dados que você pediu para alterar e os dados das outras variáveis como estão salvar no banco.
  1. Na aba Tests é feito um tipo diferente de teste, onde além de verificar se o ID é um número ele vai verificar se o ID da resposta é o mesmo ID da variável global criada pelo POST, por isso essa variável global não pode ser alterada manualmente, somente pela requisição POST.

GET ALL

  • É utilizado para buscar todos os dados do objeto da requisição.
  • Tipo de resultado: Status Code 200 OK
  • Funciona da mesma forma do outro GET by ID, onde é feito uma operação chamada READ no banco de dados.
  • Nomenclatura dessa Requisição: Read All <Nome do Model>
  1. Deve apresentar no Response todos os objetos que estão salvos no banco do objeto passado na url.

DELETE

  • É utilizado para [deletar por id] um registro no banco de dados pelo ID passado na URL.
  • Tipo de Resultado: Status Code 200 OK.
  • Graças ao DELETE, podemos fazer uma operação DELETE no banco de dados.
  • Nomenclatura da Requisição: Delete <Nome do Model>
  1. Deve apresentar no Response o ID do objeto excluido.
  2. Nos testes é verificado se o ID da exclusão é o mesmo que o ID salvo na variável global criada pelo POST, por isso essa variável global não pode ser alterada manualmente, somente pela requisição POST.
  3. Após deletado e apresentado o ID e verificado, é limpo todas as variáveis globais.

VALIDATIONS

  • VALIDATIONS é o nome do diretório onde se encontram todas as requisições das validações dos dados do objeto, cada validação deve ter sua própria requisição.
  • Essas requisições servem para testar possíveis erros que podem acontecer na requisição, se um dado não pode ser nulo ou falta alguma informação.
  • Eles são rodados como qualquer uma das requisições acima.
  1. Para cada variável ou objeto, deve ter um diretório interno com suas requisições de validação
  1. Essas requisições devem dar as mensagens de erros definidos nas validações do DTO
  1. Todas as requisições vão dar o tipo de resultado 400 Bad Request e no Response vai ser apresentado a mensagem definida para o tipo de erro
  1. Nos testes é somente verificado se realmente foi o status 400 que ocorreu

Rodando todos os testes ao mesmo tempo

  • No postman podemos rodar todas as requisições na ordem que colocarmos elas.
  • Isso ajuda a não ter que rodar uma a uma para testar se tudo está certo.
  • Todas as requisições devem estar na seguinte ordem:
  • Após estar na ordem correta e seguindo o padrão apresentado em cada uma das requisições do CRUD, iremos selecionar a pasta do CRUD e vai mostrar a seguinte página:
  • Ao clicar no botão Run na parte de cima dessa página, irá trazer todas as requisições criadas na ordem que estão no diretório, onde o postman irá verificar elas em ordem os testes definidos na aba Tests
  • São os testes das requisições que importam, onde todos verificam o status que deve retornar da requisição, alguns irão verificar o ID salvo com a variável global(PUT e DELETE) e alguns irão salvar o ID na variável global (POST), por isso que é importante eles estarem em ordem, porque eles vão fazer o seguinte:
    • O POST vai criar o objeto, salvar no banco e pegar o ID e salvar na variável global.
    • O GET vai verificar se o dado está no banco salvo mesmo
    • O PUT vai alterar o dado do banco com um dado passado no body, onde o teste vai verificar se foi feito alteração e se os IDs estão iguais
    • O GET ALL vai trazer todos os dados salvos do banco
    • O DELETE vai deletar um dado, verificar se o ID do dado deletado é igual e apagar as variáveis globais
  • Uma requisição utiliza a requisição anterior para fazer algo, estão encadeadas, por isso é importante estar na ordem correta.
  • Ele vai mostrar em verde e com a mensagem Pass se a requisição passou no teste definido na aba Tests
  • Para os testes serem validados pelo revisor, TODAS AS REQUISIÇÕES DEVEM ESTAR PASSANDO NOS TESTES.
  • é muito importante o revisor verificar se passou todos os testes e se no banco foi realmente alterado os valores, por isso o revisor deve testar um a um vendo se estão fazendo o que devia e depois testar todos ao mesmo tempo usando o runner do postman.

Clone repository

Principal


  • {\color{red}Área \space Inicial}
  • {\color{darkorange}Instalação \space de \space Programas}
  • {\color{lime}Design \space dos \space Mockups}
  • {\color{darkgreen}Gerenciamento \space da \space Equipe}
  • {\color{darkblue}Processo \space de \space Desenvolvimento}
  • {\color{indigo}Organização \space das \space Squads}
  • {\color{violet}Arquitetura \space dos \space Projetos}
  • {\color{purple}Banco \space de \space dados \space - \space Infos}
  • {\color{darkcyan}Retrospectivas}

Áreas das Squads

{\color{black}\boxed{\color{darkgreen}\mathbb{Página \space Inicial \space do \space BACKEND}}}

{\color{black}\boxed{\color{darkblue}\mathbb{Página \space Inicial \space do \space FRONTEND}}}

{\color{black}\boxed{\color{darkorange}\mathbb{Página \space Inicial \space do \space DATABASE}}}