Variables
Variables are how the executable API metadata expresses data dependencies between graph steps: a value produced by one call is parked under a key and replayed into a later call’s request. ReṼoman resolves variables as it executes the graph, passing data between steps:
-
Variables, e.g.,
{{variable-key}} -
Nested variables, e.g.,
{{variable-key{{nested-variable-key}}}} -
Dynamic variables, e.g.,
{{$randomUUID}},{{$randomEmail}}
Variable resolution precedence
In the case of collision between variable keys, the precedence order to derive a value to replace a key is:
-
The three persistent Postman scopes, in this order (narrowest wins, matching Postman):
-
pm.environment— the mutable environment built during execution (also seeded from the Postman Environment file / dynamic environment supplied through config) -
pm.collectionVariables -
pm.globals
-
So a key present in the environment shadows the same key in collectionVariables, which in turn shadows globals. The same chain backs pm.variables.get(key) inside scripts. Only an environment-scope hit feeds the mutable environment write-back and the warm-run ledger; collectionVariables / globals hits resolve read-only.
Variable naming convention: for Dynamic variables populated from Java code, use $ within a variable to indicate it needs to be populated during manual testing, e.g.: {{$unitPrice}}.
|
Custom Dynamic variables
ReṼoman comes bundled with some Dynamic variable generators. If the in-built dynamic variables don’t fit your needs, you can plug your own generator by providing an instance of CustomDynamicVariableGenerator. This is invoked to generate a value for your custom variable-key in the template at runtime.
| Custom dynamic variable generators have the top-most precedence for variable resolution. This can be leveraged to override variables set via any other way. |
Related
-
Mutable Environment — how resolved values accumulate into the mutable environment across the run.