Postman: Testes de APIs como se eu tivesse 10 anos [part II — Testes > Requests]

“O que hoje é verdade, amanhã pode ser mentira.”

Pimenta Machado

Dando continuidade ao primeiro post, hoje falaremos da importância de se testar nossas APIs, bem como um pouco de minha trajetória com isso.

Em algumas experiências que tive com testes em APIs REST era muito comum eu solicitar a outros profissionais exemplos de como interagir com suas APIs. Geralmente eu recebia projetos no SOAPUI ou collections no Postman aonde era possível encontrar uma série de requisições a um dado endpoint.

Quando eu ia inspecionar mais a fundo as requisições porém, eram só requisições e nada mais.

O problema com as requisições é que elas informam como solicitar algo, não o que você deveria esperar caso ela funcionasse corretamente, logo, você nem sabe se aquilo de fato está “funcionando” atualmente.

Minha jornada até agora

Dando um pouco de contextualização, comecei a trabalhar com testes de APIs no SOAPUI. Uma das grandes vantagens que ele possuía era uma série de componentes de testes, como testes de SLA, testes de resposta, testes de HTTP Status Code, dentre outros.

No SOAPUI, a diferença entre requisições e testes é bem clara, pois os testes ficam em uma área separada, conhecida como Test Suite, em que é possível criar Test Steps, Load Tests e Security Tests.

O SOAPUI é uma excelente ferramenta para te dar vislumbre de quais tipos de testes você pode fazer, porém, possui alguns problemas, dentre os quais eu poderia citar:

  • A interface não é tão amigável;
  • Consumo de memória caso sejam abertas várias abas de testes;

Além dos pontos acima, minha mudança de ferramenta de testes se deu pela dificuldade de interagir com a minha equipe na AIS, eles me falaram de uma outra ferramenta de testes chamada Postman.

De fato a interface do Postman é muito mais amigável que a do SOAPUI e os meus problemas com a memória do computador também pararam.

Porém, o maior preço que tive que pagar foi a ausência de componentes para testes, era preciso escrever todos os testes em JavaScript, o que não é uma linguagem que nutro uma profunda admiração, porém, não dá para querer ignorá-la no mundo de desenvolvimento de software hoje em dia.

Outra dificuldade que senti no Postman é a de nunca saber se a coleção de testes que tenho salva na minha máquina está atualizada, isso porque ainda não encontrei uma forma de sincronizá-lo com meu computador sem exportar sempre as minhas coleções. Explicarei um pouco mais sobre isso quando formos falar sobre Continuous Integration.

De qualquer forma, o que é importante que fique bem claro aqui é o porquê devemos testar nossas APIs.

Qualquer certeza em um mundo de incertezas é um alívio. Saber que algumas premissas são válidas em um dado cenário nos dão tranquilidade e segurança de que não estamos indo em uma direção errada.

Um outro problema, como bem disse Pimenta Machado, é que o que hoje é verdade, amanhã pode ser mentira, e em se tratando do mundo de desenvolvimento de software, a frase se encaixa como uma luva.

Uma simples requisição não vai nos “notificar” caso algo mude de um dia para o outro. Escrevi há um tempo atrás sobre minhas considerações do porquê testar, e para não me tornar repetitivo, recomendo a leitura do seguinte post.

O que aprendemos?

  • Testes > Requisições;
  • O que é verdade hoje, amanhã pode ser mentira

No próximo post falaremos mais sobre o Postman propriamente dito.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade