Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Given/Then/When/And included in string passed to step regexes #170

dwt opened this Issue Aug 22, 2011 · 8 comments


None yet
8 participants

dwt commented Aug 22, 2011

We noticed that "Given/Then/When/And" is included in the string that is passed to the step regexes. We think that is the reason why most lettuce steps are written without ^ and $ to delimit the matching regexes, this makes it hard for developers to write strict regexes.

For us this has lead to the problem that a step definition with a short regex caught the step that was intended for a step with a longer regex (e.g. lettuce_webdriver's "should see" vs "should see in seconds").

This took us quite some time to debug. :-)

In Cucumber only the part after the given/when/then/and prefix is handed to the steps for matching, with the reasoning, that the prefix is only for the writer of the steps to make it easier for him to show his intent, but not for the step definitions, which should work with any of the prefixes. I.e. in Cucumber you could even replace Given/When/Then/And by asterisks and it would still work just the same.


gabrielfalcao commented Aug 23, 2011

I agree, and thanks for openning the ticket. I'm gonna work on it ASAP, I miss that in my workflow too :)

@ghost ghost assigned gabrielfalcao Aug 23, 2011


I just ran into this too. Only seems to happen for me if I have a parenthesized element at the start of the regex. For instance:

@step('(.+) and other stuff')

vcarel commented Feb 28, 2013

We've been tricked too. In our case, we had steps beginning with the same string, e.g.:

@step('user specifies a new password')
@step('user specifies a new password and saves')

I agree with with dwt's idea of not sending Given/Then/When/And, but I would also match the regexp against the whole string too.


adaschevici commented Dec 5, 2013

I did a little debugging and checked out the various scenarios here.
It seems the step regex matching is working properly now.
It matches the closest matching occurrence in a non-greedy fashion.

I think this can be closed.

I'd happily do this myself, but I've unsuccessfully set up all the dependencies for the Makefile, so I'm giving up. However, I suggest the following:

  • Create new decorators: @given, @when, and @then
  • They can (should?) expand on the existing @step
  • Each decorator can prepend/insert (Given|And), (When|And) or (Then|And) after checking for the ^

Potential issues:

  • This may need to change the Gherkin parser to contain some state information when reading .feature files though.
  • Given and When can, at times, be somewhat arbitrary.

danni commented Jan 21, 2014

@adaschevici: it still passes the prefix into the step.

@graham-malmgren: that's more or less what Behave does. Some of the steps I've written include a STEP_PREFIX which is basically ^(Given|When|Then|And)


adaschevici commented Jan 21, 2014

Yes. I noticed this but it no longer fails to differentiate between steps when one is a prefix of the other.
The pattern matching was done previously in a greedy fashion and now it's non greedy so I am thinking this fixed the issue here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment