Easy Postman Tests: A Quick Guide

As a Quality Assurance Engineer, you may encounter backend errors while performing web functional testing. This is usually caused by a lack of documentation, team communication issues, or other process-related issues. If there is no Swagger or similar tool, and you do not have access to the backend source code, the time before you can start testing the API will increase. Postman helps with API testing without having to involve other team members. All you need is to install Postman and understand which backend service you need to test.

In this article, we’ll look at the case of the Spotify API that we can find at any-api.com. All I have to do is click on the “Sign in to execute” button, select the API that I want to use, and log in to Spotify. 

I’m pretty sure you’ve seen a page with numerous playlists from streaming services, where you can pick one and turn it on. We will need the GET /browse/categories endpoint to test the function that returns a list of these playlists. To transfer this request to Postman, we will need to:

• Open Chrome Dev Tools with the Network tab selected,
• Send this request by using any-api website,
• Use the copy as cURL (bash) option,
• Import this request to Postman,
• And save it to our collection.

Let’s check the request works, and we can get a list with categories.

When we have verified that the request has been imported correctly, we can open the tests tab and begin writing tests. 

To cover basic tests, you can use the snippets on the right. We would not be QA engineers if we didn’t check out Postman’s new artificial intelligence assistant, Postbot, which is currently in beta. Now, let’s open it and ask it to add tests for this request.

We can see that it added four tests, one of which checks the status code and three of which checks the types and values of the fields inside the response body.

If we don’t think about the logic and ease of these tests, the first thing that comes to mind is:

1. These tests only cover the case in which we receive a status code – 200. If a 500th error happens, all the tests will fail, and it will be difficult to blame them. But do we need to run all the tests if the status code is not 200?
2. In each test, we store the response in a variable, and then we check the fields in each test.

Let’s try to improve our tests by using a more flexible response declaration and checking for a status code before running other tests.

To ensure the purity of the experiment, let’s take the next request

browse/categories/{category_id} using the same logic that we used to add the first request.

To make it more similar to an approach that can be used at work, we can put the URL and access token used in the two tests in a variable, and category_id in the Path Variables. 

We should get something like this:

We can determine the structure of the response by passing the ID of the first category to the category_id path variable. From the previous request, we can find this ID – “toplists”, and send this request.

{

  href,

  icons: [

    {

      height,

      url,

      width

    }

  ],

  id,

  name

}

We can use this structure to store our response in the tests tab and add a check for status code. This structure should only work for success cases. 

If we have a different structure for 404 or 401 status codes, we can add those cases below.

Now we will be able to pass values into tests without writing a “response.”, and If there is a status code that we don’t expect, the tests won’t run.

And that’s pretty much it!
Feel free to use this little guide whenever you need it.