Dynamic Statements Data Supported in Pickle Execution

Pickle Test Suite will automatically detect and execute certain Gherkin statements to assist in the execution of testing. This ability can be used to generate dynamic data during the execution of scripts. Executing Dynamic Data statements creates a temporary cache of most variables that can be used in:

  • Other statements in the same scenario.
  • Later scenarios in the same script.
  • Across scripts in a test plan (configured in the test step editor).
  • To decide which tests steps are executed in a test plan (test step evaluation criteria).

The concept of Gherkin is that a test script is totally self-contained. Whilst this is still the primary aim, in the real world, test scripts will need to interact and gather data generate by systems for later test steps.

During execution, when Pickle finds a statement it can help with, it will complete that step automatically.

Consider the scenario that you need to create a date of birth (randomly) for an individual. You would typically write something like this:

Given that I enter a date of birth in the DOB field
Then I confirm that the DOB Field contains a date of birth
It would work but does not specifically validate the actual input because it is cannot be pre-recorded in the script. Pickle provides standard syntax to help with that situation:
Given I select a date between "1 Jan 1940" and "31 Dec 2000" then record it to {All-DOB}
Then I confirm that the DOB Field contains {All-DOB}
When Pickle encounters these statements it :

  1. Generates random a date between the specified dates automatically and passes the step (with a relevant comment).
  2. Displays step 2 to the tester with {All-DOB} replaced with the generated date.

For example, if the date generated was 22 March 1974, the statement the tester is asked to execute would be:

Then I confirm that the DOB Field contains 22 March 1974

Scope and Data

Data is created and updated dynamically at the point the statement is reached. It then exists and is usable in any subsequent scenarios. For example:

  Scenario: Field does not exist (too early)
    Given I display {All-id}
    Then it will not work because it does not exist yet

  Scenario: Generate ID
    Then I record a unique value to {All-id}
    Then I enter the ID into a field
  Scenario: Data Traverses Scenario's
    Given that I can see the following id : {All-id}
    And I can see the ID string "{All-id}"
    Then the above will work because the data is created in the previous scenario

Audit and Reporting

Auditing the data recorded/generated is a key element of this functionality. It is audited in 3 ways:

  • When data is recorded/generated, the comment in the test step records what has been recorded.
  • When a step uses data previously generated, the step is updated to include that data. This ensures there is no ambiguity.
  • The end-of-execution report, displays the above two items and provided a summary of all generated data (in its final state) at the bottom.

The short answer is yes. They generally fail for only a few reasons:

  1. The parameter data is invalid (e.g. you enter an invalid date where a date is required).
  2. Where the statement requires user input, the tester cancels that input.
  3. A fault in Pickle (we have tested it but …) 8-O m(

When an error occurs

  1. an error message is shown to the tester.
  2. the step is automatically failed
  3. the error/issue is recorded to the comment for that step.
  4. The standard Pickle workflow is followed (i.e. the tester will be asked if they wish to fail the whole scenario).
  • wiki/pickle/supported_statements/dynamic.txt
  • Last modified: 29/05/2019 11:50
  • by ThinkingEngine