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”.
Hello, I’m also looking for the best and easy solution for this problem and it looks like Postman still hasn’t implemented the one I need… Actually, what I’d like to have here is just the counter for the request within the run. Something like info.interation but not within the request. So it would cover all the needs and make it possible to run separate folders of tests, etc. (not checking the request name, not moving the script to one specific request, not adding the unnecessary logic for checking the token expiration etc.). We only need to have an ability to see that this exact request for this exact run has counter 0. Then we run our code.
Hi @kalgin. Welcome to the Postman Community 
.
To be sure I correctly understand your questions, you want to be able to programatically keep track of the number of times a request has been ran in a series of iteration in the collection runner? If yes…
Postman does not provide an explicit way for you to do this but there are a couple of workarounds that can help you achieve the same.
Hi @gbadebo-bello ,
no, the initial issue is that it’s not possible to run a script only once, without inventing wheels. So let’s say I have a collection with folders, i.e. 200, 400, 404 (status codes) with a number of requests in each. And I want to run the login method and get the access token before running tests and only once. Any tweaks with variables don’t suite me because it’s really annoying and even not possible out of the box to keep track on this value and reset it (I can’t use post-request script as this way it will be connected to some specific request which I don’t want to do, because it won’t be possible to run only one folder with tests if this request with post-request script is not there).
So what I really want is just being able to run scripts once) Not for each request, just for the collection. I’ve created the feature request with these 2 options: adding the pre-collection script OR adding the ability to get the request index (in terms of collection, i.e. if I have 100 requests in 1 collections, I should be able to distinguish (not by name) if the currently running request has index 0). So both options would work. It’s really strange that this feature is still not added) I believe it’s the case 100% of teams need - login once and keep the token in env.
I am not sure I understand you clearly.
You’re using the collection runner to run a collection and you want it to be structured such that there’s a specific request that can only be ran once and every other time you click the run button, that request is omitted and does not get run by the collection runner. Is this correct?
No, the pre-collection request should be run every time you run the collection. It’s very simple - it’s not pre-request but pre-collection script. If you ever created large test suites where you need to use a token, I wonder how would you do it with Postman) Currently the only “normal” (for CI) solution I know is just using the script in the pre-request script tab for the first request of the suite. But it’s a bad solution because it’s not convenient when you need to run some specific request only (it hurts only for local debugging/updating, so it’s OK for the CI but still I don’t like this solution).
Just having read a lot of requests in this forum, I believe this feature needs to be added as it’s pretty obvious that it’s needed and there are no workarounds (and just in case: no, collection envs don’t suit here either)
For your use case, having the request that helps you “set up” the collection as the first request in that collection should work for your use case. Then, subsequent requests can be organized into folders. You can move the order in which requests and folder are ran in a collection.
So for example, this requests can be the “login” request that gets the authorization token and stores it in a variable for re-use.
As I said, this is what I’ve already done (I have the first request in the run that does this). But it’s a bad solution because it won’t work if you want to run some other request only. So, it’s pretty obvious that Postman needs this feature. All other workarounds cannot replace it