You can clone with
HTTPS or Subversion.
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.
I agree, and thanks for openning the ticket. I'm gonna work on it ASAP, I miss that in my workflow too :)
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')
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.
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:
@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)
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.