Using environments in collection runs
Environments allow you to create robust requests that can be re-used. Read more about using variables and environments.
Environments can also be used in the Collection Runner. Let’s look at an example collection, with one POST request that uses environment variables in its URL, body, and test script. Download the sample collection: collection.json.
The test expects the value of foo in the response body to be equal to bar. Let us also assume that after some computation, we’re resetting the value of this variable to bar2.
To run this collection correctly in the Collection Runner, you need to supply it the corresponding environment. Download the sample environment: environment.json. In the Collection Runner, if we select our test environment from the environment dropdown on the left and run the collection, you’ll see the tests pass.
If you switch back to the main Postman app window and check the value of the variable foo, you’ll see that it is now bar2.
This is because, by default, any variable changes in the environment (or globals) in the Collection Runner will be reflected in the main Postman app window since Persist Variables is checked in the options. In fact, if you run the collection once again, you’ll see that it will now fail, since we changed the value of the variable foo.
By default, Persist Variables is checked the first time you open the Collection Runner. If you do not want variables to be updated during the run, deselect the Persist Variables checkbox. In this case, think of it as the Collection Runner saving the initial state of the environment (and globals), and restoring it after the run is complete. This is useful when you reuse the same variables in your requests and want to run the same collection multiple times. This will also make sure that the environment (and globals) state is not affected by a collection run.
