Behave: Writing A Scenario Outline With Dynamic Examples

Gherkin / Behave Examples Gherkin syntax features test automation using examples: Feature: Scenario Outline (tutorial04) Scenario Outline: Use Blender with Giv

Solution 1:

I've come up with another solution (behave-1.2.6):

I managed to dynamically create examples for a Scenario Outline by using before_feature.

Given a feature file (x.feature):

Feature:VerifysquarednumbersScenario Outline:Verifysquarefor<number>Thenthe<number>squaredis<result>Examples:Static|number|result|
  |   1    |    1   | 
  |   2    |    4   |
  |   3    |    9   |
  |   4    |   16   |
# Use the tag to mark this outline@dynamicScenario Outline:Verifysquarefor<number>Thenthe<number>squaredis<result>Examples:Dynamic|number|result|
  |   .    |    .   | 

And the steps file (steps/x.step):

from behave import step

@step('the {number:d} squared is {result:d}')defstep_impl(context, number, result):
    assert number*number == result

The trick is to use before_feature in environment.py as it has already parsed the examples tables to the scenario outlines, but hasn't generated the scenarios from the outline yet.

import behave
import copy

defbefore_feature(context, feature):
    features = (s for s in feature.scenarios iftype(s) == behave.model.ScenarioOutline and'dynamic'in s.tags)
    for s in features:
        for e in s.examples:
            orig = copy.deepcopy(e.table.rows[0])
            e.table.rows = []
            for num inrange(1,5):
                n = copy.deepcopy(orig)
                # This relies on knowing that the table has two rows.
                n.cells = ['{}'.format(num), '{}'.format(num*num)]
                e.table.rows.append(n)

This will only operate on Scenario Outlines that are tagged with @dynamic.

The result is:

behave -k --no-capture
Feature: Verify squared numbers # features/x.feature:1

  Scenario Outline: Verify square for1 -- @1.1 Static  # features/x.feature:8
    Then the 1 squared is 1# features/steps/x.py:3

  Scenario Outline: Verify square for2 -- @1.2 Static  # features/x.feature:9
    Then the 2 squared is 4# features/steps/x.py:3

  Scenario Outline: Verify square for3 -- @1.3 Static  # features/x.feature:10
    Then the 3 squared is 9# features/steps/x.py:3

  Scenario Outline: Verify square for4 -- @1.4 Static  # features/x.feature:11
    Then the 4 squared is 16# features/steps/x.py:3

  @dynamic
  Scenario Outline: Verify square for1 -- @1.1 Dynamic  # features/x.feature:19
    Then the 1 squared is 1# features/steps/x.py:3

  @dynamic
  Scenario Outline: Verify square for2 -- @1.2 Dynamic  # features/x.feature:19
    Then the 2 squared is 4# features/steps/x.py:3

  @dynamic
  Scenario Outline: Verify square for3 -- @1.3 Dynamic  # features/x.feature:19
    Then the 3 squared is 9# features/steps/x.py:3

  @dynamic
  Scenario Outline: Verify square for4 -- @1.4 Dynamic  # features/x.feature:19
    Then the 4 squared is 16# features/steps/x.py:31 feature passed, 0 failed, 0 skipped
8 scenarios passed, 0 failed, 0 skipped
8 steps passed, 0 failed, 0 skipped, 0 undefined
Took 0m0.005s

This relies on having an Examples table with the correct shape as the final table, in my example, with two rows. I also don't fuss with creating new behave.model.Row objects, I just copy the one from the table and update it. For extra ugliness, if you're using a file, you can put the file name in the Examples table.

Solution 2:

Got here looking for something else, but since I've been in similar situation with Cucumber before, maybe someone will also end up at this question, looking for a possible solution. My approach to this problem is to use BDD variables that I can later handle at runtime in my step_definitions. In my python code I can check what is the value of the Gherkin variable and map it to what's needed.

For this example:

Scenario Outline: Use Blender with <thing>
     Given I put "<thing>"in a blender
     When I switch the blender on
     Then it should transform into"<other thing>"

    Examples: Amphibians
        | thing         | other thing            |
        | Red Tree Frog | mush                   |
        | iPhone        | data.iPhone.secret_key | # can use .yaml syntax here as well

Would translate to such step_def code:

@given('I put "{thing}" in a blender')defstep_then_should_transform_into(context, other_thing):   
  if other_thing == BddVariablesEnum.SECRET_KEY: 
    basic_actions.load_secrets(context, key)

So all you have to do is to have well defined DSL layer.

Solution 3:

Regarding the issue of using SSN numbers in testing, I'd just use fake SSNs and not worry that I'm leaking people's private information.

Ok, but what about the larger issue? You want to use a scenario outline with examples that you cannot put in your feature file. Whenever I've run into this problem what I did was to give a description of the data I need and let the step implementation either create the actual data set used for testing or fetch the data set from an existing test database.

Scenario Outline: Accessing the admin interface
  Given a user who <status> an admin has logged inThen the user <ability> see the admin interfaceExamples: Users
  | status | ability |
  | is     | can     |
  | isnot | cannot  |

There's no need to show any details about the user in the feature file. The step implementation is responsible for either creating or fetching the appropriate type of user depending on the value of status.