[rspec-devel] [Cucumber] --guess option to choose between Ambiguous step definitions when appropriate

Jake Howerton jake.howerton at gmail.com
Fri Jan 30 14:04:14 EST 2009

Hey Peter,

Not sure I follow what you are saying, or how changing the regex solves the
problem at hand.  Both regex's would still get matched by default with your
form.  Also, not sure how the nested grouping would effect what gets passed
to the block.

Am I missing something in your comment?


On Fri, Jan 30, 2009 at 1:39 PM, Peter Fitzgibbons <
peter.fitzgibbons at gmail.com> wrote:

> How about forming your regex as follows?  You're writing a Grammar Parser
> (via regex's), so you have to think grammar parsing:
> Then /the form has a field called: (.*) (with value: (.*))?/
> Yes, this gets you a longish list of matchers... the evil of grammar
> parsing.
> What do you think?
> Peter Fitzgibbons
> (847) 687-7646
> Email: peter.fitzgibbons at gmail.com
> IM GTalk: peter.fitzgibbons
> IM Yahoo: pjfitzgibbons
> IM MSN: pjfitzgibbons at hotmail.com
> IM AOL: peter.fitzgibbons at gmail.com
> 2009/1/30 Jake Howerton <jake.howerton at gmail.com>
>> Hey All,
>> I discussed this option with Aslak in #cucumber and think I convinced him
>> of its value ;)  Please chime in with any thoughts.
>> This feature is currently available in my github fork here:
>> http://github.com/jakehow/cucumber/tree/master
>> Please pull and test if this matters to you or you are curious.
>> Way back in Story Runner ;), the order you defined your steps in
>> mattered.  This allowed you to put steps in a specific order if you had more
>> specific steps that you wanted to match first.  ( Aslak tells me this was a
>> bad idea, b/c different OS's order Dir[] differently).  Either way I found
>> it useful, because it allows you to make a more specific step definition
>> instead of contorting your English in order to avoid multiple matches. Every
>> time I sit down with cucumber, I hit this issue, in cucumber you can at
>> least make more specific regex's, but this is also a pain, especially in
>> complex situations.
>> Say we have two step definitions.
>> Then /the form has a field called: (.*)/
>> and
>> Then /the form hThen /the form has a field called: (.*) with value:
>> (.*)/as a field called: (.*) with value: (.*)/
>> By default this will raise a Cucumber::Multiple error because of the
>> ambiguousness of it from the regex standpoint.   However, it is not really
>> ambiguous for the user who entered the step:  Then the form has a field
>> called: name with value: Jake.  My changes will pick the appropriate step,
>> when you have the --guess option turned on.
>> How it works:
>> There is ranking logic that gets invoked when the option is turned on:
>> - The step definition with the most capture groups wins
>> - If there are 2+ definitions with the same amount of capture groups, the
>> one with the shortest overall captured string length wins
>> - If there are still 2+ options the Ambiguous error is raised
>> I am pretty happy with how accurately this ranking works for how I intend
>> to use it, but it is not perfect.  Let me know your thoughts about this,
>> method names, and my implementation ( which I think is pretty ugly atm).
>> Particularly, I had to inject the config option into StepMother, and had to
>> change some stubs in other specs in order to accomodate this.
>> Also it is probably slow b/c I test the matches multiple times, should
>> this be cached within the best_matches method body?  Is there a better way
>> to select the top matches, etc.
>> Thanks,
>> Jake
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20090130/2e6ab39b/attachment.html>

More information about the rspec-devel mailing list