Hey all,
First of all, it was great meeting some of you that attended the Postman event. For those attended, I hope you enjoyed or got something out of my talk 
I’ve been asked to upload the slides I used during my talk but the slides on their own are pretty pointless, as 90% of the content was me talking over images. So I’ll just upload the code examples used in the last third of the slides.
For those that didn’t attend or need their memory jogging - this is about using “hooks” in your Postman Collections.
What Does That Mean? - This means I’m using the same “Register User” request BEFORE EACH collection. This allows me to keep my Postman tests DRY (Don’t Repeat Yourself) and this makes it easier to maintain.
Example Test Collection:
As you can see, each collection has numbers next to them.
What this means is, when I run the entire collection via the Collection Runner or Via Newman, all the requests in the “Before Each Hooks” sub-collection are ran, followed by “Register User”, then we go back to the “Before Each Hooks” sub-collection and run those requests again and finally we run the requests in the “Edit User” sub-collection.
I do this by making use of a “counter” variable that has a numerical value and by using the “setNextRequest” command.
In the “Setup” request - I’m just hitting a dummy request but our “counter” variable is set to 0 at this point.
**In the Pre-Request for “Before Each > Register User” ** request I’m taking the current value of the “counter” env variable and saving it as a regular JS variable. I am then clearing all environment variables and resetting the counter env variable back to what it was (Why am I doing this? - This request is hit BEFORE EACH sub-collection and I don’t want any persisting env variables - hence the “environment.clear”
I agree this is a stupid way of performing this task, so please feel free to give this feature request a heart:
https://community.postman.com/t/allow-users-to-lock-certain-environment-variables-so-theyre-not-overwritten-removed/3255
In the “Tests” tab for “Before Each > Register User” request - I am getting the current value of the counter env var and converting it to a regular js variable so it’s cleaner to work with. Notice how I’m using parseInt on the env var as all env variables are saved as string values.
Ok, so - If our counter variable is 0 then we use setNextRequest to go to the first request in the “Register User” sub-collection. If we didn’t have this step, the collection run would naturally go that sub-collection anyway. If it’s value is 1, then we go to the first collection in the “Edit User” sub-collection.
If it’s none of those values, we use a null value. This will end the collection run.
Here’s the code in the Test tab for the last requests in each sub-collection.
This increases the value of the counter variable by 1.
And it uses setNextRequest to go back to our Register request.
And here’s some example tests I would write on the Register request as an added bonus
This is obviously the most basic example I can give on this topic, but here’s how I’m using it at my current place of work.
We’re currently working on improving the ways customers return an item for a refund, repair, replacement etc. This backed by a Returns API.
Here’s a section of my Returns collection:
So BEFORE EACH sub-collection in the “[A] Returns” folder is run, all the requests in the “[A0] Hooks: Before Each Customer Return” is run. This means I only need to worry about maintaining one POST request that actually creates the return record in our DB instead of having this reuqest duplicated in every sub-collection.
I, unfortunately, can’t show the requests inside the sub-collections - but all you need to know is there’s a POST request that creates the actual Return record in the [A0] collection.
So imagine the POST request in the [A0] collection is the last request in that collection, here’s how I’m deciding which collection to “jump” to:
In the previous example, I was using an IF statement for simplicity. But here I’m using a SWITCH statement.
Instead of using a counter, I’m using an env variable called “targetTestSuite” this is just set to a string value to determine which collection to jump to next.
So by default, it goes to the [A1] collection, it’ll run all the requests inside that and use setNextRequest to jump back to our [A0] collection. The last request in [A1] will set the targetTestSuite var to the value “Overdue”.
So now we’ll be in the last request of [A0] which creates the Return record and targetTestSuite is set to “Overdue” this means it will now jump to [A2].
This will keep happening so the collection run will do this:
A0, A1, A0, A2, A0, A3, A0, A4, A0, A5, AX
Feel free to read more on setNextRequest:
https://learning.getpostman.com/docs/postman/collection_runs/building_workflows/
Also, be mindful to make your request names unique as setNextRequest will go to the LAST matching request name. So if I had several requests named “GET User” we would get an undesired behaviour as setNextRequest would always jump to the last “GET User” request.
Apologies if this is explained poorly…it’s pretty late and I’m tired
Cheers!
