In the first part of the article, we were dealing with the basic terminology and logic of API testing. We’ve gone through the basics of API testing, HTTP requests and responses, status codes, JSON objects, etc. Now it’s time to put the theory to practical use.

In the second part of the article, we will explain how to do basic API testing in Postman app. We decided to use Postman because it features everything needed for a comprehensive API testing process, it’s fast and powerful and, best of all, it’s free! After we’ve explained how to use Postman for API testing, we will show you how to automate that process in a way that tests can be run with a single click.

Postman 101

After installing the latest version of Postman app on your computer and running it, you will probably see something similar to this:

In the beginning, Postman screen might seem a bit confusing to you, but don’t worry, you’ll get the hang of it pretty soon.

First thing you should do is to create an environment for your tests. Environment is mostly used to distinguish tests for different kinds of deployment environment, so you might have, for example, local environment, or test environment, or perhaps production environment. Let’s say you’re doing the testing on your local server, so you decide to call the environment “Local Environment”. Note that creating multiple environments is not a mandatory thing, but it’s very practical if you’re testing different deployment environments.

After creating an environment, you should create your first collection. Collections are, in a sense, “boxes” which contains all your tests, test folders, sub-folders, etc. for a certain project or several projects. We will name this collection “Test Collection”.

Now that we have an empty collection, it’s time to fill it up with some requests. For the purpose of demonstration, we will create, modify and delete an entity called “co-op”. This entity represents a business or organization whose members are, in this case, dairy farmers. Dairy co-op uses the milk produced by its members’ cows to make foods like cheese and yogurt.

Although it’s not really necessary, my personal “best practice” is to divide API tests for different entities and/or functionalities into different collection folders. Therefore, we will create, in this case, a folder called “co-op resource”.

In the folder, we will create a request called “post new co-op”, as seen on the image below:

Each new request will be set as “GET” by default, so you have to change it manually to “POST” in this case. Finally, we have an empty POST request. Let’s see what we have to do to create a new co-op.

First of all, we must provide an endpoint. Currently, my local backend server is running, so my URL looks something like this: http://localhost:8080/api/coops. After we’ve specified the endpoint, we are faced with several Postman functionalities which can be seen on the image below:

Before we can send the request to the server, we must have proper authorisation, otherwise, server will reject our request. There are different kinds of authorisation used nowadays, which means you will probably have to ask developers in your team which one you’ll be using. For more details on authorisation, please see Postman documentation (https://www.getpostman.com/docs/v6/postman/sending_api_requests/authorization).

After you’ve entered the correct authorisation data, you will have to specify which content type you’ll be using for your request. In our case, we will be using JSON file, so we’ll put content type as “application/json” in Headers (picture below).

This can also be done by going to Body section and categorising body as “raw/JSON”. You can now enter your request data in the body.

If you need to generate some pre-requisite data from JavaScript code for your request, such as current timestamp or something similar, you can use Pre-request Script section for that.

Note that there is also a section called Params. This is section where your parameters are stored. It is useful when your endpoint requires you to enter some additional parameter to your request. For example, if you want to test entity filtering, you will usually have to enter the endpoint, then specify, using a parameter, which filter you want to use on the list of entities. The server will respond with filtered values only, instead of responding with the full list of entities.

Okay, we’ve got it all, there’s only one more thing before we proceed – tests. This is, arguably, the most important part in the API testing process. You need some assertions for the expected output, otherwise, you will have tests which always pass, and that is something you really don’t want to happen. Your assertions belong in the Tests section. For this demonstration, we will assert that the server has to return response with the status code 201 Created. Note that Postman comes with some out-of-the-box test code snippets which represent the assertions you will probably use most of the time, so they’re a very good place to start learning. In time, with some basic knowledge of JavaScript code, you may modify those snippets or create completely new ones, depending on what you need.

We’re ready to go! We will save our changes and click “Send” button.

There it is! Our first entity is officially created! Note that server responded with both request data and some other data generated by server itself. Take special notice of server-generated “id” attribute – this is the unique ID of the entity in the database. Memorise or write down this ID because you will need it in the further testing to identify that specific entity. Although the status code 201 Created is displayed in the Body section, you can also go to Test Results section and verify that your assertion is set as “PASS”. Also, if you need some additional information about the response, you can get them in Headers section.

The next step could be, for example, to get the complete list of admin users and verify that your user is on the list. You just add another request after this one, with GET method set. You shouldn’t need to put anything in the body and your assertion should be to get the status code 200 OK. Try something like that for yourself and see what happens.

We will focus now on updating the entity we’ve created with different data and using the aforementioned ID to identify the specific entity to be updated. Create new request and set its method to “PUT”. It’s very similar to POST method, so you can just copy the whole body from the POST request. However, one thing should always be added – the ID. So if we wanted to change the main phone number of the co-op in our scenario, our PUT request would look something like this:

It’s important to remember to always add ID to PUT requests. If you don’t add the ID, you have two most likely outcomes: 1. server will reject the request with status code 400 Bad Request, 2. new entity will be created because server cannot find the existing entity without the ID.

For PUT requests, expected status code is the same as with GET requests – 200 OK. So we’ll just provide that assertion in Tests section. Let’s send the request and see what happens:

That’s it! You’ve updated the entity. Notice that main phone has been updated with the data provided in the request.

DELETE method functions the same way as GET – you don’t need to put anything in the body. However, you might have to provide the ID as a parameter or directly in the URL. Of course, expected status code is 200 OK as well.

How to do it automatically

So, we’ve learned how to add a new entity, view the list of entities, update the entity and then delete it. However, we did all of that manually, that is, we had to write down the ID, pass it in the next request and, in the end, run all requests one by one. In this section, I will show you how to fully automate the process. This means that you’ll have to “catch” the ID somehow and then pass it to the other requests. This is done with Postman variables.

There are two kinds of variables in Postman: environmental and global variables. Environmental variables are attached to one environment and can only be used within it. Global variables, on the other hand, can be used anywhere in the app.

Why do we need variables in Postman? Variables in Postman exist so that a certain value can be passed to multiple requests without user having to re-enter that value over and over again manually. They are especially useful when you have to change the value in all requests – you just go to the list of variables and update the variable with the new value. The alternative would be to go to every single request which features that variable, which can be very cumbersome and usually leads to a higher probability of mistake.

Solution for automating our test scenario is, as mentioned before, pretty simple – we just have to send the ID value to variable and we can reuse it as many times as we want. How do we do that? First of all, we need to parse the JSON body we got from the server response to POST method. When we parse a JSON file, we convert strings to JSON objects. This way, we can easily access any attribute-value pair within the JSON object. The code for parsing JSON object looks something like this:

Note that this is not the only way to parse JSON in Postman, but I personally find it as the simplest. After we’ve parsed the response body, it’s time to access the “id” attribute and extract its value. We can both extract the ID value and set it as the environmental variable in just one line of code, as shown below:

Let’s analyse what we’ve done here. Firstly, we’ve called Postman and told it that we want to add a new variable to environmental variables list – “pm.environment.set” part does that. To specify the value that will be passed to variable and the variable name (or alias, if you like), we’ve added the part in parentheses. As you can see, “id” is the name of variable, and we pass “jsonData.id” value to it. Accessing attributes in JSON objects is pretty simple – in this case, we needed the id, but we could’ve done the same thing with other attributes as well; for example, if we wanted to pass the co-op’s short name as value, we would have written it as “jsonData.shortName”.

Try to run the request again, this time with the variable code included. Notice that now your variable can be seen on the list of environmental variables.  Also, notice that the variable has the same value as the ID displayed in the response.

After you’ve done that, the second step is to take the variable and use it in another request. We’ll go back to PUT request now and we will substitute number value of the ID with the variable. It’s going to look like this:

To pass the variable in Postman, you have to put the variable name in double curly brackets. This way, Postman knows it’s looking for a variable. Time to run the request again. Congratulations, you’ve just completed the basic API testing automation! You can now go to Postman Runner and run the complete folder with tests as many times as you want.

So, our whole process can be summarized in few words: create entity, view entity, modify entity, delete entity (provided that your API endpoint features that functionality). You can also do a simple cleanup of the environment variables list by unsetting all the variables in one of your requests after using them. It’s even easier to unset the variable than to set it, as shown in picture below.

Concusion

I’ve guided you through the basics of API testing – first we’ve learned some essential things about API testing and then we’ve gone through a simple automation process. There is lots of other things to be learned from both Postman and API testing in general, and the best thing to do is to experiment with them and see how far they can take you.

If you want to gain a better understanding of Postman, I strongly recommend their online documentation, which can help a lot in the learning process. Also, you can benefit greatly if you learn some basic JavaScript syntax and methods. With that knowledge, you’ll be able to master Postman and the API testing in no time.

I sincerely hope this article has been useful to you. It may not be the most comprehensive guide out there, but I do believe it’s a good starting point for those who want to learn more. I also hope that the article has been enlightening for you in some degree and that it will push you to try out new things, the same way I did once, because you never know what you might find. Maybe even a better testing future for yourself.