Blog post
If you are wondering how to write automated tests for an API, you are in the right place to learn it! All you need is a tool, motivation, and patience. First, let’s introduce you to Postman.
Postman is a collaboration platform for API development. It is also a powerful tool for testing and understanding APIs that you yourself or others have created. Using automated API testing to test various endpoints in your API will help you find bugs as quickly as possible, as your focus needs to be on early testing. This way you can leverage Postman for Backend testing while your Frontend is still being developed.
To understand the point of automated testing in Postman, follow these simple steps and create your own test suite.
Set up Postman
First, we need to install Postman. After installation and when Postman is opened, the Postman workspace is displayed. To start writing tests, we need to create our own collection, an area where the API requests are organized.
Next, we need an environment in which to define our variables. Variables are used to save time and once defined, we can use them in all our tests. They make requests more flexible and readable.
After we have created the collection and environment, we need a variable {{baseURL}} to be used in all the tests. In this example, we will use the same URL as in the image below, as this is a base URL that never changes.
Instead of always putting a URL in the request, we will call {{baseURL}} in all the requests. When mentioning requests, we should specify the types of methods that will be used in our requests. The GET method is used by default by Postman and is used to retrieve data from an API.
Other methods are:
- POST— add new data
- PUT—replace the existing data
- PATCH— make a partial update of the existing data
- DELETE—delete the existing data
Now, let’s do some business and write test cases!
Write test cases
Example of writing automated tests related to a simple booking.
The first test case is login, where we create a token to access the application. This is followed by cases where we create a simple booking with corresponding data and use the method GET to retrieve this created booking. Further cases are the ones where we update and partially update the created booking and finally the case where we delete the created booking. We will also go through cases where tests passed and failed.
1. Auth - Create a token
As mentioned in the previous section, we need to create a login to access the application. The first request is POST to create a new token that will be used for access to the PUT and DELETE booking.
The variable {{baseURL}} that we defined in the previous section is used in the request with the path /auth, this is our URL. Then we need to set the value application/json in the header, Content-Type (format of the sent payload).
In the body of the request, we need to send authentication. So enter the following in the body:
And if you send this created request, you will get a token in the response. And there’s the question of how we can confirm that that’s exactly what happened. Well, we can write a test.
In our test cases, we can write simple and complex tests to verify what we received from the requests we sent. Examples of simple tests are checking the corresponding response, checking the header, and receiving tokens, as we’re going to do now. On the tests tab, we write tests.
The first test is checking the corresponding response:
pm.test() is the function that allows Postman users to name the test exactly, and the function accepts 2 parameters, the name of the test (as a string) and a function that returns a boolean value.
Second, we need to check that the response is Content-Type JSON and that the response contains a valid token:
If we run these simple tests, we should get a result like in the picture below. All 3 tests have passed.
If we want to create a booking, we must have a token. Therefore, we need a new variable to store the token from the response. The first test — checking the appropriate response and if a token was created. We can store the token received in a new variable called token as follows:
2. Create a booking
Now let’s do some complex tests and create a booking. The request is also POST, since we are creating a new booking. For the URL, we will use the variable {{baseURL}} with the path /booking . On the Headers tab, we define the Content-type and Accept parameters (in which format the response body is returned) as in the figure below.
In the body, we define parameters such as first name, last name, booking dates, etc.
In the Tests tab, we would check that we have received the booking ID and that the booking ID is stored in the new variable “bookingID1”. The variable is used in the following tests that check if the user can edit, receive and delete the booking. We would also check that the content type is JSON and that each parameter is valid.
The tests should pass, and if we check the Test Results tab in the Response section, we should get 10 passing tests, as shown below:
3. Get Booking
If we want to check the booking we created in the last step we need to send a GET request with {{baseURL}}/booking and the created variable from the section below {{bookingID1}}.
In this case, we can check whether we have received the appropriate booking. First, we need to check if the response status is OK, the content-type is JSON, and the parameters are correct.
Our 6 tests should pass as shown below:
4. Update a booking
There are some situations where the user wants to update his booking. So we’ll also create a case where we update the person’s name. We will add Ana Smith instead of Lucas Smith. If we want to update it, we need to call the method PUT with {{baseURL}}/booking and the ID of the booking {{bookingID1}}.
As you can see in the header, we need to set an authorization token to access the PUT endpoint, which can be used as an alternative to authorization. So at this point we call our created variable token where the token is stored.
In the body section, change the value for the firstname.
We can now check that the reservation has been updated and that all fields have been filled in correctly.
And of course, 9 tests should pass.
You can also GET this updated reservation and check if the person’s name has been updated. Use the example from step 4 and try it yourself.
5. Partial update booking
What if the user wants to change only the “booking data” and “additional needs”, which immediately increases the price? In this case we need to use the method PATCH, with which we will be able to perform a partial update. The URL contains the base URL and the booking ID, which we want to partially update. An indispensable part is the authorization token, which is the same as in the last section.
In the body, we change the total price, the booking data, and the additional needs.
Now we test if all the fields are filled in correctly and if the booking is partially updated. These tests should pass.
You can check this partial update using the method GET from step 4 and make sure that the data is correct.
6. Delete booking
If we want to delete our created booking, we use the method DELETE. The URL is the same as in the previous case and only an authorization token needs to be set in the header.
In this case, we use simple tests such as checking if the booking is deleted and the status code is “Created”.
These simple tests should pass as shown below:
But what if we want to retrieve our created (now deleted) booking? If we write a test on the way that we want to retrieve our created booking as follows:
Our test fails and an explanation for the failed test is visible in the test results. We cannot retrieve our created booking because it is deleted and cannot be found.
7. Run collection
We have reached the last part, where we will run all the tests we have written, that is, we will run the test suite. To run the test suite, open the collection in which the tests were written.
The tests will run in the order they are listed in the collection, but you can move them around if you want to change the order of execution. You can deselect a single request by unchecking it. Moreover, you can specify the number of iterations for your collection run and the interval delay (milliseconds) between each request.
We had tests that passed and failed in the section above. Now we will run the collection with the last test that fails to see how it is present in the collection run.
The Get booking test fails during the collection run and is listed as failed because our created booking was deleted and cannot be retrieved. Also, we can see the explanation in the run collection.
On the other hand, if we use the last test Get booking where we confirm that our booking is deleted, the test passes during the collection run and is listed as passed. This is because our created booking is deleted and cannot be retrieved so the status code should be 404 instead of 200 like the previous one.
Postman also provides its users with the ability to share the results of a collection run by exporting them from Collection Runner for others to analyze. To export a collection run, we need to open it in Runner (using History on the left, if the run is not already open).
Then, we need to click on Export Results in the upper right corner to download the run and choose a location to save the downloaded collection run.
You can use this guide to create your own tests for the application. If you have any problems writing your tests, or have any further questions, please feel free to contact me.
Good luck!
