Introduction
In Postman, the utilization of Runners significantly benefits software testers. These Runners can mainly be employed in two distinct methods within the platform.
To ensure the APIs are working as expected which can be linked together. e.g., Post request to add a record in DB -> GET request to confirm it has been added -> UPDATE/ DELETE request to update/ delete a record from DB -> Confirm the record has been updated/ deleted. (This can also be attained by chaining calls together with "Send Request" in the "Test" script of Postman)
The second is to test multiple test scenarios with a single click. But we must have the TCs automated in Postman to achieve this task. Postman has a very comprehensive guide on how to automate the TCs in Postman. This blog post is about the second use of runners.
In certain situations, you may encounter numerous scenarios for the request body of an API, each with a unique response for the corresponding request payload. How can you efficiently test the test cases automated in Postman in such instances? Manually running the request for each test scenario would be time-consuming and laborious. Additionally, how would you handle any changes in the API development process? This is where Runners become an invaluable tool, as they facilitate the regression testing of APIs.
To better comprehend the functionality and advantages of Runners, we will employ a Mock API created using mock servers in Postman. If you are unfamiliar with the utilization of Mock Servers in Postman, I recommend referring to the Postman documentation or my blog on creating mock servers. The mock server will simulate the behavior of the actual API, which will be developed by the team's developers.
Rules for the API Being Tested
To demonstrate the application of runners in API testing, we will examine an API that returns the shipping fee, taking into consideration factors such as membership status, cart items price, and delivery method.
If the order is a pick-up order, no shipping fee will be applied.
If the order is a shipping order, the shipping fee will be based on the following factors.
Active members won't be charged any shipping fees.
Inactive members would be charged a shipping fee if the order amount after discounts is less than $35. The shipping fee would be:
a. $6.99 for Standard Shipping
b. $13.99 for Prime Shipping
Test Cases for the API
By the stipulated guidelines, the following test cases have been provided for your reference. While additional test cases may be devised, these examples should sufficiently demonstrate the functionality of Postman runners.
delivery method is "pick up"; amount < $35; amount after discounts < $35; membership is inactive (shipping fee = 0)
delivery method is "pick up"; amount = $35; amount after discounts < $35; membership is inactive (shipping fee = 0)
delivery method is "pick up"; amount > $35; amount after discounts = $35; membership is inactive (shipping fee = 0)
delivery method is "pick up"; amount > $35; amount after discounts > $35; membership is inactive (shipping fee = 0)
delivery method is "standard"; amount < $35; amount after discounts < $35; membership is inactive (shipping fee = 6.99)
delivery method is "standard"; amount = $35; amount after discounts < $35; membership is inactive (shipping fee = 6.99)
delivery method is "standard"; amount > $35; amount after discounts = $35; membership is inactive (shipping fee = 0)
delivery method is "standard"; amount > $35; amount after discounts > $35; membership is inactive (shipping fee = 0)
delivery method is "express"; amount < $35; amount after discounts < $35; membership is inactive (shipping fee = 13.99)
delivery method is "express"; amount = $35; amount after discounts < $35; membership is inactive (shipping fee = 13.99)
delivery method is "express"; amount > $35; amount after discounts = $35; membership is inactive (shipping fee = 0)
delivery method is "express"; amount > $35; amount after discounts > $35; membership is inactive (shipping fee = 0)
delivery method is "pick up"; amount < $35; amount after discounts < $35; membership is active (shipping fee = 0)
delivery method is "pick up"; amount = $35; amount after discounts < $35; membership is active (shipping fee = 0)
delivery method is "pick up"; amount > $35; amount after discounts = $35; membership is active (shipping fee = 0)
delivery method is "pick up"; amount > $35; amount after discounts > $35; membership is active (shipping fee = 0)
delivery method is "standard"; amount < $35; amount after discounts < $35; membership is active (shipping fee = 0)
delivery method is "standard"; amount = $35; amount after discounts < $35; membership is active (shipping fee = 0)
delivery method is "standard"; amount > $35; amount after discounts = $35; membership is active (shipping fee = 0)
delivery method is "standard"; amount > $35; amount after discounts > $35; membership is active (shipping fee = 0)
delivery method is "express"; amount < $35; amount after discounts < $35; membership is active (shipping fee = 0)
delivery method is "express"; amount = $35; amount after discounts < $35; membership is active (shipping fee = 0)
delivery method is "express"; amount > $35; amount after discounts = $35; membership is active (shipping fee = 0)
delivery method is "express"; amount > $35; amount after discounts > $35; membership is active (shipping fee = 0)
Illustration of a Few Test Cases
Allow me to provide a clear representation of the anticipated API request and response through specific examples.
The following image demonstrates a typical API request and its corresponding response in a scenario where the membership status is inactive, the shipping method selected is pick up, and the order amount post-discount is less than $35.
In the subsequent illustration, a representative example of an anticipated API request and response is depicted, wherein the membership status is inactive, the chosen shipping method is standard shipping, and the order total after discounts amounts to less than $35.
In the following illustration, another typical example of a projected API request and response is demonstrated, where the membership status is active, the selected shipping method is prime shipping, and the order total post-discount exceeds $35.
All the payloads for the test cases written above can be accessed from the Git repository.
Configure Runner Request
Upon successfully configuring the mock requests and responses, the subsequent step involves setting the body to retrieve the payload from the JSON file.
Create separate request
Set variable for body data in pre-request
Use the variable in the request body as demonstrated below
pm.collectionVariables.set("request_payload", JSON.stringify(pm.iterationData.toObject()));
The body of the runner request would look like this:
Writing the Test Script
Upon completing the configuration of payloads, establishing the body, and implementing the pre-request script, we shall proceed to develop the test script. Each test case within the script will execute for every request payload when utilizing the runner. The subsequent image illustrates the test script, which can be accessed from the Git repo. Feel free to incorporate additional test cases according to your requirements.
Setting Up Runner
With the prerequisites in place for executing the test cases, we can now proceed to configure the runner with a JSON file. To do so, please adhere to the following steps:
Click on the runner button in the bottom right of Postman. A window will open similar to the one displayed below.
Drag and select the runner request in the 'Run order' area.
Choose the JSON file containing all payloads. The file must have an array of all payloads. Each element in the array is considered a payload.
Executing Runner
Upon initiating the runner, all test cases will be executed for each payload within the file. Subsequently, the request, headers, and responses can be observed for each run execution.
Summarizing
In the article, we discussed the use of Runners in Postman for automating and streamlining the testing of multiple API scenarios with a single click. Runners are essential for regression testing of APIs and help save time by avoiding manual testing for each test scenario. The article also mentions the use of a Mock API created using mock servers in Postman to demonstrate the working and benefits of Runners.
It is my sincere aspiration that the insights provided within this article will contribute to enhancing your proficiency in API testing. I look forward to engaging with you in future articles. In the meantime, maintain your well-being, stay connected, and continue your pursuit of knowledge.