Setup

This module contains steps that can be in both Background: and Scenario: sections.

Then variable value ask

Then ask for value of variable "{name}"

[view_source]

Tell grizzly-cli that it should ask for an initial value for the variable.

It will inject the value into the locust runtime environment, and in this step read it and insert it into the locust context which grizzly will use to setup locust.

If grizzly-cli is not used, one has to manually set the environment variable, which requires a prefix of TESTDATA_VARIABLE_ and the suffix should match the variable name in question.

Use this step for variables that should have different initial values for each run of the feature.

Example:

And ask for value for variable "AtomicIntegerIncrementer.messageID"

Arguments:

name str - variable name used in templates

Given variable value

Given value for variable "{name}" is "{value}"

[view_source]

Step to initialize a variable that should have the same [start] value for every run of the scenario.

If this step is used after a step that adds a task or for a variable that already has been initialized, it is assumed that the value will change during runtime so a Set variable task will be added instead. The Variables must have implemented support for being settable.

Data type for the value of the variable is based on the type of variable. If the variable is an testdata Variables then the value needs to match the format and type that the variable has implemented. If it is not a testdata variable grizzly will try to guess the data type. E.g.:

"10" becomes int
"1.0" becomes float
"True" becomes bool
everything else becomes str

It is also possible to set the value of a variable based on another variable, which can be usable if you have a variable in multiple scenarios which all should have the same initial value.

Example:

example.feature

Feature:
    Background:
        And ask for value of variable "messageID"
        And value for variable "HelloWorld" is "default"
    Scenario:
        And value for variable "AtomicIntegerIncrementer.mid1" is "{{ messageID }}"
        And value for variable "AtomicIntegerIncrementer.persistent" is "1 | step=10, persist=True"
        And value for variable "AtomicCsvWriter.output" is "output.csv | headers='foo,bar'"
        ...
        And value for variable "AtomicCsvWriter.output.foo" is "{{ value }}"
        And value for variable "AtomicCsvWriter.output.bar" is "{{ value }}"

If the file features/persistent/example.json (name of feature file and feature extension replaced with json) exists, and contains an entry for the variable, the initial value will be read from the file and override the value specified in the feature file.

Arguments:

name str - variable name
value Any - initial value

Then execute python script with args

Then execute python script "{script_path}" with arguments "{arguments}"

[view_source]

Execute python script located in specified path, providing the specified arguments.

The script will not execute on workers, only on master (distributed mode) or local (local mode), and it will only execute once before the test starts. Available in the scope is the current context object and also args (list), which is shlex.split of specified arguments.

This can be useful for generating test data files.

Example:

Then execute python script "../bin/generate-testdata.py"

Then execute python script

Then execute python script "{script_path}"

[view_source]

Execute python script located in specified path.

The script will not execute on workers, only on master (distributed mode) or local (local mode), and it will only execute once before the test starts. Available in the scope is the current context object.

This can be useful for generating test data files.

Example:

Then execute python script "../bin/generate-testdata.py"

Then execute python script inline

Then execute python script

[view_source]

Execute inline python script specified in the step text.

The script will not execute on workers, only on master (distributed mode) or local (local mode), and it will only execute once before the test starts. Available in the scope is the current context object.

This can be useful for generating test data files.

Example:

Then execute python script
  """
  print('foobar script')
  """

Given set context variable

Given set context variable "{variable}" to "{value}"

[view_source]

Set a context variable.

If used in the Background-section the context variable will be used in all scenarios and their respective user. If used in a Scenario section it will only be set for that user.

If this step is before any step that adds a task in the scenario, it will be added to the context which the user is initialized with at start. If it is after any tasks, it will be added as a task which will change the context variable value during runtime.

Variable names can contain (one or more) dot (.) or slash (/) to indicate that the variable has a nested structure. E.g. token.url and token/url results in {'token': {'url': '<value'>}}

It is also possible to have spaces in a variable names, they will then be replaced with underscore (_), and the name will be converted to lowercase.

E.g. Client ID results in client_id.

Example:

And set context variable "token.url" to "https://example.com/api/auth"
And set context variable "token/client_id" to "aaaa-bbbb-cccc-dddd"
And set context variable "token/client secret" to "aasdfasdfasdf=="
And set context variable "token.resource" to "0000-aaaaaaa-1111-1111-1111"
And set context variable "log_all_requests" to "True"
And set context variable "validate_certificates" to "False"

Arguments:

variable str - name, can contain . and /
value str - value, data type will be guessed and casted