Unlock the full potential of Postman for efficient API testing
API testing is an important part of software development, but it can be a time-consuming and repetitive task when done manually. Postman is one of the most widely-used tools for testing APIs. However, its automation capabilities are often not fully utilized by many users, which leads to a less efficient API testing process.
At JULO, we initially did not take advantage of Postman’s automation features, resulting in manual testing for every API, including those that were already stable and in production. For example, we would manually hit the “Send” button 20 times for executing 20 test cases for a single API. In the case of integration tests where a single test case required hitting multiple APIs, such as 10, we would manually hit the “Send” button 200 times. This approach was extremely time-consuming and prone to errors, hindering our productivity.
Today, we only perform manual tests on APIs that are still in development, or in certain situations where automation may not be the best option, such as exploratory, ad-hoc, usability, and edge cases testing. For stable APIs already in production, we rely on automated testing using pre-written test scripts for efficient and accurate results.
This post is for you, who are looking to boost efficiency by automating API testing or are simply eager to explore new techniques. I’ll walk you through the process step-by-step of creating automated tests in Postman, covering Integration and Data-Driven test automation.
The Frustration of the Tedious Manual Steps
In this post, we will be utilizing the Postman Collection below. It’s worth noting that the APIs used in this demonstration are from gorest.co.in, which provides a free-to-use fake REST API service intended for testing purposes.
The names of the requests are clear and self-explanatory. However, for the sake of context, let’s assume these APIs pertain to a typical online forum system, which includes functionality for creating users, posts, comments, and deleting users.
Integration testing often involve using data from one API’s response as a parameter in another API. For example, in order to test the ‘Create Post’ and ‘Delete User’ API, the User ID obtained from the ‘Create User’ API’s response must be added to the URL.
Similarly, the ‘Post Comment’ API’s URL requires the Post ID obtained from the ‘Create Post’ API’s response. These steps can be tedious and time-consuming, especially when testing a real-world system that typically involved multiple APIs beyond just 4.
As experienced testers, we also want to perform negative tests on each API in addition to Integration testing. Let’s consider some sample negative test cases for the ‘Create User’ API.
Eight. That’s the number of times we had to manually hit the “Send” button, not to mention the added effort of having to manually modify the request body between each hit.
Let’s not delay any longer and begin automating these APIs. I will divide this process into two sections: Integration and Data-Driven.
Automation — Integration Test
Step 1: Use Variables
We could streamline the process by storing the User ID from the ‘Create User’ API response in a variable and then utilizing it in the URLs of both the ‘Create Post’ and ‘Delete User’ APIs, rather than manually copying and pasting it repeatedly.
The task can be accomplished simply by including a small JavaScript code snippet in the Tests section of the request. Once the request is sent, Postman will automatically execute the code in the Tests section.
Now that the User ID has been stored in a collection variable named “user_id”, let’s examine the collection variables. The “user_id” variable should now hold the value of the User ID retrieved from the response.
Finally, incorporate the variable within the URLs of both the ‘Create Post’ and ‘Delete User’ APIs.
Since the ‘Post Comment’ API’s URL requires the Post ID obtained from the ‘Create Post’ API’s response, let’s do the same.
At the end of this step, the need for manual data copying and pasting between API responses and URLs will be eliminated.
Step 2: Create Assertions
Assertion is a critical component of automation, as it allows us to determine the success or failure of a test.
Similarly, assertions can be included in the Tests section of a request. Since it is not feasible to cover all possible types of assertions in one blog post, we will specifically focus on the process of adding assertions for the status response code and response body of a request.
Let’s test it out by sending the request and looking at the Test Results section.
Great! Now that we’ve applied the same process to the remaining of the APIs (which won’t be covered in this post), let’s move on to the final step!
Step 3: Use the Postman Collection Runner
Although we have completed step 1 and 2, we still need to manually hit the “Send” button for each API. Postman Collection Runner automates the process by running all the APIs within a collection. Keep in mind that it runs them sequentially, so ensure the order of the APIs in the collection is correct before starting the runner.
- Click on the three dots located next to the collection name and select Run collection.
2. Hit the “Run <collection name>” button.
3. Voila!
With this, the Integration test has been automated, allowing for easy and effortless execution at any time.
Automation — Data-Driven Test
Step 1: Set Up the Requests
The goal of this process is to create sets of test data in a CSV file, store them in a collection variable, and then send the request a specified number of times, based on the number of rows (as test cases) in the file.
- Create a CSV file and input the necessary test data
2. Assign a separate variable for each attribute’s value
3. In the Pre-request Script section, add the code to retrieve the test data from the CSV file and store it in the collection variables. Note that Postman will automatically execute this code before sending the request, unlike in the Tests section.
Step 2: Create the Assertion
The image illustrates the result of the “check if name is empty” test case.
As all test cases will return a status response code of 422, it is appropriate to hard-code this value as the expected response. Additionally, we will need another “test” to display the description of each test case. No assertion is required for this informational purpose.
Step 3: Upload the CSV file and Run the Collection
Before running the collection, upload the CSV file containing the test data. Postman will automatically detect the number of iterations.
Hit the “Run <collection name>” button.
From the results, we can see that all the assertions pass. We can drill down on the details of each assertion to verify, like in the example below of checking when the name parameter is empty.
Great! We can observe that all the requests sent match the test data provided in the CSV file. The Data Driven automated test is now complete!
Start automating and make your life easier!
When I first joined JULO, I was part of a squad, whose main focus was on API testing. My day-to-day tasks involved manually testing these APIs. At first, the job was straightforward as I was only testing a few APIs for an existing product, and I had several QA colleagues working on the same product.
Over time, things changed when I was the only QA assigned to test a new product, which consisted of over 10 APIs. The time it took to manually execute integration tests and thorough negative tests on each API was too much, and the added challenge was that since it was a new product, these APIs were still under development and unstable. This meant that if a developer made changes to the code due to additional requirements or bug fixes, I had to retest everything again to avoid any regression issues. Suddenly, the job was not as easy as it seemed.
I prepared for my interview at JULO by watching a Udemy course on Postman, initially skipping the Automation section as it wasn’t in the job description. However, due to that frustrating experience, I later revisited the section and learned about Postman Automation, which I implemented in my work and found to be highly beneficial. Despite some initial extra effort, the automation greatly simplified the testing process by reducing the need for manual execution. Even when changes to the automation script were needed due to requirement changes, the effort was minimal compared to manual testing.
I proposed this approach to the QA Lead, who recognized its value and encouraged me to share it with the team. Now, the use of Postman Automation is a standard practice at JULO.
We have gone through the process of creating an Integration Test and a Data-Driven automated test using Postman. With this, you should now have a good understanding of how to automate your API testing using Postman.
So, let’s start automating to make your life easier!
Thank you for reading, and good luck!
