Postman: APIs’ testing as if I were a child [part II — Tests > Requests]

“What is true today, tomorrow can be a lie.”

Pimenta Machado

Continuing the first post, today we will talk about the importance of testing our APIs and a bit of my test trajectory.

It is very common in my REST APIs experience to ask other professionals for examples of how to interact with their APIs. Generally, they send me projects in SOAPUI or collections in Postman where it is possible to find a series of requests to a given endpoint.

When I was going to inspect that requisitions more thoroughly, they were just that, requisitions and nothing more.

The problem with requests is that they tell you how to send something, not what you should expect if it works correctly, so you do not even know if it is actually “working” at all.

My journey so far

I started working with API tests with SOAPUI. The great SOAPUI test advantage is a series of test components, such as SLA tests, response tests, HTTP Status Code tests and so on.

SOAPUI gives you difference between requests and tests very clearly. SOAPUI tests are in a separate area, known as Test Suite, where you can create Test Steps, Load Tests and Security Tests.

SOAPUI is an excellent tool to give you a glimpse of what kind of tests you can do, but it has some problems, such as:

• The interface is not user-friendly;
• Memory consumption with several opened tab;

In addition to the above points, I changed my test tool due to the difficulty of interacting with my team in AIS, they told me about another test tool called Postman.

Postman UI is more friendly than SOAPUI. My computer memory problems have also stopped.

However, there are no test components in Postman, I should write all tests in JavaScript. JavaScript is not a language that I have a deep admiration for, but you can not ignore it in the world of software development nowadays.

Another difficulty I had with Postman is that I never know if the test collection I have saved on my machine is up to date because I have not yet found a way to synchronize it with my computer without ever exporting. I’ll explain a bit more about this in Postman Continuous Integration part.

Anyway, what’s important to be clear here is why we should test our APIs.

Why test your API?

Any certainty in an uncertainty world is a relief. Knowing that some premises are valid in a given scenario gives us peace of mind and assurance that we are not going in the wrong direction.

Another problem, as Pimenta Machado said, is that what is true today, tomorrow may be a lie, and in the world of software development, the phrase fits like a glove.

A simple request will not “notify” you if something changes tomorrow. I wrote a while ago about my considerations of why to test, and to not become repetitive, I recommend reading the following post [portuguese version].

What have we learned so far?

• Tests > Requisitions;
• What is true today, tomorrow can be a lie.

In the next post, we’ll talk more about the Postman itself.