dynamic variable for `timeZone`

[nickAdlard]

Is your feature request related to a problem? Please describe. Not really a problem, it's more that there are a number of unsupported faker data, for example address.timeZone.

Describe the solution you'd like Specifically I'm after a dynamic variable for a random time zone, like $randomTimeZone. In one runner execution, I need to be able to create multiple unique items with different timezones.

Other related solutions:

1. more random faker dynamic variables.
2. possibly just supporting faker in the sandbox.
3. maybe some sort of native support for loading a file on disk as a dynamic variable. Then each time it's used it randomly picks a line from the file.

Describe alternatives you've considered

1. importing faker as an external js package. This request could be filled by putting faker in the sandbox as well.
2. using a data file with one row that has a giant list of timezones. Then randomly picking from the list in a pre-request script.
3. like 2, putting a list of timezones in an environment variable directly. But postman gets slow with a lot of data in environment vars.
4. I think I'll go with this solution: have a file on disk that's a list of timezones, use shuf to pick 1, then use the --env-var option with newman to pass in the random pick.

Additional context I develop collections and runners in postman then execute them in newman in a scheduling/orchestration system.

I have a runner setup to create multiple items with various attributes(like timezones, lists of strings, integer amounts), it then does some work with them, updates them, destroys them. It checks the state of these items and their attributes along the way. Passing in an env var only gives me 1 to timeZone use, meaning I can only create 1 item. I kinda need to use multiple items at once.

This runner is wrapped up and executed in a scheduled job, these scheduled jobs are very generic one liners like newman run $PM_COLLECTION -e $PM_ENVIRONMENT. Any more complexity added to scheduled jobs means means more things to maintain.

This is why dynamic variables are nice, they can be used many times in one runner to create many unique things. If I can keep all the complexity in one system like postman/newman, and in one collection or runner, it would be ideal. Once I start refactoring to do work in the scheduling system or maybe breaking up into multiple collection runners, I guess it's just more to think about.

[DannyDainton]

Hey @nickAdlard

If you're using Newman primarily, could you use that as a library and bring in faker to use anything that module has to offer?

const newman = require('newman'),
      faker = require('faker');

newman.run({
  collection: 'collection.json',
  reporters: ['cli'],
  reporter: {
    cli: {
      noSummary: true
    }
  },
  envVar: [
    { 
      "key":"timezone", "value":`${faker.address.timeZone()}` 
    }
  ]
})

[nickAdlard]

@DannyDainton ooo this is very cool and will help, thanks.

I'll add this context to my request as well: I have a runner setup to create multiple items with various attributes(like timezones, lists of strings, integer amounts), it then does some work with them, updates them, destroys them. It checks the state of these items and their attributes along the way. Passing in an env var only gives me 1 to timeZone use, meaning I can only create 1 item. I kinda need to use multiple items at once.

This runner is wrapped up and executed in a scheduled job, these scheduled jobs are very generic one liners like newman run $PM_COLLECTION -e $PM_ENVIRONMENT. Any more complexity added to scheduled jobs means means more things to maintain.

This is why dynamic variables are nice, they can be used many times in one runner to create many unique things. If I can keep all the complexity in one system like postman/newman, and in one collection or runner, it would be ideal. Once I start refactoring to do work in the scheduling system or maybe breaking up into multiple collection runners, I guess it's just more to think about.

[dparadisZentelia]

+1