Postman Series — I: You Need a Temp Storage
Using environment / global variables as an inter-request memory to build sophisticated scenarios.
In Postman there are three different places that you can use as a storage:
- Environment Variables
- Global Variables and
- Data Variables
Environment variables are mostly for providing some environment-specific variables like your base URL instead of hardcoding them into your requests and responses. It makes your collection ready-to-run for different environments such as your localhost or your dev server.
Global variables are very similar to environment variables besides its name and purpose, so you can put the variables which are common to all of your environments like maybe enums or repetitive request payloads in it.
Lastly, the data variables is basically an array of iteration data. In postman you can run a collection multiple times in one click and in each iteration you can use different set of variables with the help of data variables. I think this feature is thought to be for providing different sets of input to the endpoints. So you can test your endpoints with multiple sets of input to make it more robust.
These being said, in reality you can and you will use these variables like a storage. In this post I will focus on how you can use environment variables and global variables as temporary storages between your requests, so you could build sophisticated testing scenarios.
How to Test CRUD Endpoints?
Let’s say you need to test your CRUD endpoints for one of your resources. Firstly, you need to make a create request and then test the response, and then try to read your resource and check if you can see the previously created endpoint, then modify it, then read it again to see if it’s modified and finally you delete it and check if it’s deleted by trying to read it again.
For all of these procedure, you need a place to store your resource ID and details since you lose all of your javascript context (scopes, variables, etc) between each script slot of each request.
What you can do is to use PM API to write to and read from the environment variables.
For example let’s inspect how you can test if your create request is really working using customers collection.
POST /customers
For this step, in the pre-request script we first generate a random customer information and store the data in the environment, then in the test script we take the customerId from response and save it again.
GET /customers/{{CUSTOMER_ID}}
Now we try to get this particular customer. Since we already stored all the information about this customer, it’s easy now to check if the response matches our expectations.
For sake of brevity I’m not going to share the UPDATE and DELETE part but they are very similar.
Conclusion
You can use environment or global variables as a temporary storage area for your requests. This is really handy for CRUD testing since you chain requests and prepare a real scenario most of the time.
Saving IDs of newly created resources or generating random user credentials is possible if you use PM API to store all the information you need.
This post is a part of the Postman series:
https://medium.com/bilgetech/our-journey-to-api-testing-with-postman-51917bd9e21b
