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:
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:
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
}
Copied
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.