Alright, I do have it working. The call to get the token only runs when it needs to. However, and I’m hoping you may have an idea, when I try to see and look at the environment variables and value, I do not see it listed in the Postman GUI! But the ensuing tests pass!
This makes me bit nervous as I don’t know WHY they would be passing IF there is no auth token listed.
Any thoughts?
Here: Store and reuse values using variables | Postman Learning Center
I found this that might explain what I am eyeball-seeing:
Variables that are defined programmatically in a script are resolved differently depending on the variable scope. This means that unresolved variables will also be handled differently. Local variables that are set programmatically using
pm.variables.setmay appear to be unresolved since they’re not stored and are only used at runtime, but if they’re set and used correctly the request will still run successfully. Environment, global, and collection variables that are set programmatically are saved for later use, so they will resolve if they’re set and used correctly. Depending on how an unresolved variable is used in a script, you may receive a400 Bad Requesterror response from the API, or Postman may be unable to send the request at all. Open the console to help identify unresolved variables in your scripts.
It should be saving the details back to the environment variables.
The tests themselves are not checking for this. The initial test just checks that the needed environment variables for the sendRequest are defined and not empty. (It doesn’t mean the values are correct). The test after sendRequest is just checking that the status of the sendRequest is 200ok, which means you haven’t had any authentication issues. (Which hopefully proves that the values are indeed correct).
It certainly does on my end, as I had to keep removing the values to test that the sendRequest() was being triggered.
The code for setting the token and expiry date environment variables will only run if both tests have passed (but we are not specifically testing that they have been updated). If either tests fails, it will immediately stop execution of all other code.
Un-remark the console log that retrieves the environment variable that shows the token expiry date. Is that working as that would prove that the environment variables are being written to. Before you run your test, ensure that the token and token expiry current values are blank within your environment (and that the correct environment is set). Please remember, console log is your friend.
On a side note. How are you running this? The web app, the desktop app, the CLI, or Newman?
Hello,
Sorry for replying so late. Got distracted and did not get any notification that you had replied.
I do thank you for the help! So now it’s working just fine. The new values are being reflected in the Postman client GUI. I don’t know what happened like I described it before where the tests were working but the GUI was not updating to reflect the values. Very strange and disconcerting. I would switch to different environments and the values of the environment variables would always stay blank/empty. We’ll see if that happens again.
I was running it via the desktop app, by clicking on the send button or via Ctrl+Enter as I usually do it. I probably also tried running it via running the whole folder but I’m not sure at this point.
I thought Newman was the cli tool for running Postman exports? Are you saying there are 2 cli tools?
They are both CLI tools. Newman runs locally using your infrastructure, where the new Postman CLI runs from the Postman cloud.
The Postman CLI tool can be downloaded independently of Postman and it can run local collection files, just like Newman.
Once it’s installed, just run it from the CLI with a local collection like this:
postman collection run <filepath>
The extra benefits of using the Postman CLI over Newman is that you can login in using a API Key and use the element ids, to run them on the CLI.
All those run results then show up in the Collection Runs tab and are also sync’d with other team members.
There are some other features in there too (API schema linting) but that’s the main difference.
Thanks for the clarification @danny-dainton. From reading the Postman CLI docs it seemed to me that Postman CLI was meant for when our Collections are being hosted by Postman, not for local environment setups. So good to know it’s not JUST for that.
I’m not sure our company will ever get to that point of hosting our collections and executing them remotely. Seems $ is tight, right now some of us can’t even have access to the Enterprise license that the company does have. I don’t know how that gets billed/charged etc. So working totally “locally”.