I have attempted to search and found a similar issue to mine here but was not able to find a solution:
I have a Postman collection, both cloud and JSON imported that works fine when running each folder.
I use this structure:
Folder A
Subfolder A
POST to create object /api/foo
GET to retrieve object /api/foo/{{some_id}}
In the tests for the POST, I set a collection variable based on the UUID that comes back from the POST. I set this like this:
pm.collectionVariables.set("some_id", id);
Now the GET request uses the newly set {{some_id}} variable, let’s say 3c87f3b8-f905-4d18-8c32-b84f4c02ed08.
In Postman - this works perfectly.
In Newman, the variable is empty and it tries an index on api/foo instead.
From what I can read, it seems that Newman sets these variables to their initial values, but doesn’t seem to allow updating them during the test cycle.
I was a bit surprised by this, and would like to know how I can change my testing approach for this to match best practice, and something that will work with Newman and Postman.
This isn’t the only scenario where I do this, but I have many examples where I need to use dynamic output from one request, and use that in further requests.
Right now I am limited to running these tests from Postman itself. Using Newman would be ideal so that I can integrate with CI, and make it easier for other engineers to run the tests.
Newman works fine with collection variables and environment variables, and you can absolutely use them between requests.
Your title says “between Newman runs” where your structure has a POST and GET request within a subfolder which I would have through would be within the same Newman command line. Could you please clarify that aspect please?
If you run the collection twice calling Newman separately, then only the initial values would be available in the second run. If that is what the issue is.
I apologize - I incorrectly mentioned, “between runs”, which was ambiguous.
What I meant by that is between the execution of each request within a folder.
newman run "my_api.postman_collection.json" -e production.postman_environment.json --folder "Folder A"
I’m running on Mac OS X, using Newman 6.0.0 installed by brew.
You are calling the environment correctly in your command line (which sometimes get missed).
This should work, I can only advise console logging the variables as soon as you set them to ensure they are being set correctly.
I don’t think the installation on MAC would make any difference, but I don’t use a MAC so I can’t guarantee this.
The console log is your friend when troubleshooting.
If you do manage to produce a test collection that can be shared, I can test this locally on windows to see if I get a different outcome. But I have collections that that have an initial authentication request that then set environment variables for authentication tokens, which work fine in the subsequent requests consuming those variables.
If you want to test the flow, you can use the Postman Echo public API.
What is interesting is that you’ve mentioned you’re setting environment variables.
Is it a possibility that collection variables do not update, but environment variables do.
I would have thought that Collection Variables would also work fine.
If I get time, I’ll fire up my DEV VM with Newman on and test this with simple requests to Postman Echo, setting a collection variable and then using that in another request (with appropriate console logs).
Ok, so I creating a very basic collection called imaginatively Newman.
Within that collection, I created a folder “Folder A”.
I have two get requests within that folder, both pointing to Postman Echo.
request1 & request2.
Request one is very simple with a query parameter called param1.
In the tests tab, I set a variable called testValue that will be used in the second request. I console log the collection variable straight after setting it to ensure its been set correctly and wrap it in a test.
const response = pm.response.json();
console.log(response.args);
pm.test("Collection variable is set to 123", () => {
pm.collectionVariables.set("testValue", response.args.param1);
console.log(pm.collectionVariables.get("testValue"));
pm.expect(pm.collectionVariables.get("testValue")).to.eql("123");
});
The second request is nearly identical apart from the name, and the query param is called param2 and is using the collection variable as the value.
You can see from the console log, that the second request is using the value from the collection variable in the URL.
Finally, running it from Newman produces the same results as per the console logs. It’s transposing the parameter in the URL for the second request as expected.
