Skip to content

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

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')
  """