行为（BDD）AmbiguousStep错误

Question

Starting play with Behave BDD test, I found there is no step definition namespace things, which can easily result in an AmbiguousStep exception. What are the best practises here? I think this will be a problem when your test project is getting bigger.

Here is what I'm trying to do:

feature-1:

Feature: feature1
  Scenario: f1s1
    When take action
    Then it's ok

feature-2:

Feature: feature1
  Scenario: f2s1
    When take action
    Then it's ok

foo4feature1.py:

@when('take action')
def step_impl(context):
    assert True

@then("it's ok")
def step_impl(context):
    assert True

bar4feature2.py:

@when('take action')
def step_impl(context):
    assert True # some other logic here according to feature2

my two features( feature-1 and feature-2 ) both have step take action . These tow steps have different meaning from each other in their scenario. They just happen to be the same name(eg, take action ). I know I can carefully pick the name of steps(eg, use "take action of f2" instead of "take action" in feature2 ) to avoid conflict. However in a big test project, you cannot ensure everybody remember the step names in everybody else's features. As a newbie in the BDD things, I'm looking for best practises to follow to handle this problem.

Answer 1

In general, you need to be concise with your steps (that is true for most BDD frameworks). Therefore, the same step within one directory scope can only have one meaning. If you need two different meanings for the same step (text), you currently need to use different directories.

In the future, behave will provide a "feature specific" scope concept. This will you allow you to exactly what you want.

Answer 2

BDD is a communication and collaboration technique. Tools exist to directly automate the examples that the customer, developer and tester discover together, but the scenarios should be written in the 'ubiquitous language' of your domain (see the book Domain Driven Design by Eric Evans).

So, the short answer is that best practice requires the collaborative definition of a shared vocabulary. The scenarios are then much easier to read and understand.... which is a good thing.

Answer 3

Adding this to the environment.py fixed my issue. You need to import parse.

@parse.with_pattern(r'[^"]*')
def parse_unquoted(text):
  """Parse/match string(s) that do not contain double-quote characters."""
  return text