Dynamic API Test Suite in Postman
More than just a REST client, an extensive API management tool.
Test Cases and suites are a vital part of software, something that has become essential in any deliverable application. In our case, we realized the importance of test cases when we had a web application in production with no test cases.
Due to code access constraints, we had to create an external test suite. Having been familiar with Postman as a REST client, we tried leveraging Postman to create the test suite. We were able to quickly create a test suite that could test the APIs with all their flows and responses. Today the test suite has been operating flawlessly for over a year and we haven’t looked back since.
In this article, we will create a test suite with dynamic requests using the features provided by Postman. The goal is to create a reusable test suite that can quickly perform unit tests, end-to-end tests, and regression tests on the APIs.
Note: A Postman test suite is not a substitute for having test cases in an application. Test cases built into the code are more flexible and offer more comprehensive coverage. In case test cases are not available in the code, a Postman test suite can provide a quick mechanism to test the APIs.
We will create a Postman test suite to test the APIs of a User Entity. The User Entity has 5 APIs for CRUD operations,
- Create User
- Get All Users
- Find User by Username
- Update User by User ID
- Delete User by User ID
Step 1: Create a Postman Collection
A Postman Collection is a group of saved requests. Collections can be created based on projects/features, whichever is more convenient. The requests can be ordered and organized into folders within the collection.
We will create a Postman collection with the name “Test Suite Demo”.
Step 2: Create Static Requests within the collection
We will create Postman requests within this collection for the 5 APIs. We will hardcode the values — URL, data, etc., into the requests.
Drawbacks of Static Requests
Static requests are easy to create but are difficult to reuse and maintain. The use of hardcoded data in the requests has significant drawbacks when any data needs to be updated.
- Common values like URL will have to be updated in every single request. This becomes extremely tedious if there are many requests.
- The data will have to be changed manually in each request if the application state or behavior changes.
- It is difficult to configure and run the requests as a single unit to test workflows in the applications.
To counter these drawbacks, we will create dynamic requests. Dynamic requests will use variables to store common values, generate random data for certain fields, and work in sync with other requests in the collection.
Step 3: Create variables for common values and values that change often
Postman variables allow us to store and reuse values in requests. Postman has 4 variable scopes. Here are the general recommendations on the use of each variable scope.
We will make the following changes,
- Create an environment, like “TestSuiteDemo-LocalEnv”.
- Add “url” as an environment variable in this environment.
- Use the Postman Dynamic variables (for random values) to generate a random name in the request body.
Step 4: Setup Pre-request scripts for more elaborate request customizations
Pre-request scripts allow greater customization of the request parameters in requests. They are commonly used to modify the request body or headers before the request is sent. It executes JavaScript code.
We will use the pre-request script to save the name of the user in a variable before the request is sent.
Step 5: Add Test Cases to test the response and perform post request operations
Test Cases in the requests can be used to validate the response of an API. These tests are highlighted when the collection or requests are run, so they provide a visual representation of the API health on the application.
The tests run after the response has been received, so they can also be used to perform post-request operations.
In this example, we will check if the response code of the API is 200 and 1 additional test case per request. And we will also store the user ID in a variable when a user is created.
Step 6: Run the Test Suite using the Postman Runner
The postman runner can run all the requests in the collection. The Postman Runner provides a quick visual of the test cases run on the API responses.
A successful response would connote that all APIs are working as required.
Any test case failure would point to some issue in the system, prompting further exploration. In this example, we can see that there was a failed test case in the Get user by User Name API.
Such a test suite can be leveraged to quickly gauge the health of the APIs. More requests can be added to test suites to validate the failure cases of APIs as well making them more comprehensive.
Conclusion
We have been using this system to test our APIs for the past year. We have 12 APIs exposed and 54 requests in the collection checking every success and failure response of the APIs. It has become our go-to testing methodology for Regression Testing and has helped us greatly ensuring that new changes do not impact existing functionality.
Caution
This testing methodology sends random data to APIs which may get persisted in the database. For our use case, it was acceptable to have this fake data in the database. Please take this into consideration and if fake data being inserted is unacceptable, run the test suite on a test or a non-production environment.
All resources used in this article are available on GitHub. The setup steps are present in the README file.
If you’re looking to delve into Postman the official docs are a good starting point.
If you have any queries, you can put them in the comments below. If you found this article helpful, please appluad, it would feel good to know that this article has helped someone 😊.
