I know that cucumber does not allow ambiguous steps to stop duplication
of specs, but I ran into the problem of only being a ble to use the
following step name once in the whole project
Then /I should see “(.*)” do |text|
What can I do to get round this?
Hello,
Can you give an example of how you would want the step body of:
Then /I should see “(.*)”/ do |text|
to be different.
I would aim for this step to be reusable. When I have conflicts I take
the approach of adding context to such a step.
Then /I should see “(.*)” in the page/ do |text|
Hence allowing different step bodies. Its up to you whether you bind
‘the page’ and case/switch on this or just have different steps.
HTH,
Joseph W.
http://www.joesniff.co.uk
Damian J. wrote:
I know that cucumber does not allow ambiguous steps to stop duplication
of specs, but I ran into the problem of only being a ble to use the
following step name once in the whole project
Then /I should see “(.*)” do |text|
What can I do to get round this?
On Sun, Sep 14, 2008 at 7:39 AM, Damian J. [email protected]
wrote:
I know that cucumber does not allow ambiguous steps to stop duplication
of specs,
It’s not to stop duplication of specs, it’s to avoid the possibility
that you could write this:
Then /I should see “(.)"
Then /I should see "(.)” in the list of authors/
Both of these would respond to:
Then I should see Aslak in the list of authors
but I ran into the problem of only being a ble to use the
following step name once in the whole project
Then /I should see “(.*)” do |text|
Not sure what you mean by this. Do you mean you can only use it one
Scenario? Or do you mean you’re looking for it to be implemented
differently in different contexts?
On Sun, Sep 14, 2008 at 9:13 AM, Joseph W. [email protected]
wrote:
Then /I should see “(.*)” in the page/ do |text|
That should raise an AmbiguousStep error if you also have /I should
see “(.*)”/. What I’ve been doing is stuff like …
Then /the list of (.) should incude "(.)"/
… in order to differentiate. I’ll say that I do allow this to impose
html element IDs:
Then /the list of (.) should incude "(.)"/ do |list_of, text|
list_id = list_of.downcase.replace(’ ‘,’-')
response.should have_tag(“ul##{list_id}”) do
with_tag(“li”,text)
end
end
But this one step covers a lot of cases for me.
Thoughts?
David
On Sep 14, 2008, at 9:39 AM, “Pat M.” [email protected] wrote:
then it should no longer match that string. Tightening up the regexs
you use should help with the ambiguous steps.
D’oh!
Thanks Pat.
David
Then /I should see “(.*)” in the page/ do |text|
That should raise an AmbiguousStep error if you also have /I should
see “(.*)”/.
Oops sorry, thanks for spotting that David.
It seems that it would be good practice to use $ and ^ in all your
regular expression steps in order to minimise surprise conflicts.
You can still use non-regular expression steps in Cucumber:
Then “I should see ‘$value’ in the page” do |value|
This issue does make me think about the regular expressions to step
matching.
My intuition would be that if a regular expression did not consume all
the tokens of a step string then it would not be a match for the step
(even though it would be in the regular expression domain). What do
people think?
I’ve been unable to think of a good example where I would want only a
partial match of a step. Throwing away the unmatched characters. Does
anyone have good examples where they would?
Joseph W.
http://www.joesniff.co.uk
David C. wrote:
On Sun, Sep 14, 2008 at 9:13 AM, Joseph W. [email protected]
wrote:
Then /I should see “(.*)” in the page/ do |text|
That should raise an AmbiguousStep error if you also have /I should
see “(.*)”/. What I’ve been doing is stuff like …
Then /the list of (.) should incude "(.)"/
… in order to differentiate. I’ll say that I do allow this to impose
html element IDs:
Then /the list of (.) should incude "(.)"/ do |list_of, text|
list_id = list_of.downcase.replace(’ ‘,’-')
response.should have_tag(“ul##{list_id}”) do
with_tag(“li”,text)
end
end
But this one step covers a lot of cases for me.
Thoughts?
David
This is what I was trying to accomplish
Then I should see “My product name”
And I should see “My product description”
And I should see “My product name was successfully saved.”
After reading all the comments above, the follwing step name solves my
problem
Then /I should see “(.*?)”$/ do |text|
Then /I should see “(.)"
Then /I should see "(.)” in the list of authors/
Both of these would respond to:
Then I should see Aslak in the list of authors
If you change the first one to
Then /I should see “(.*?)”$/
then it should no longer match that string. Tightening up the regexs
you use should help with the ambiguous steps.
Pat
On Mon, Sep 15, 2008 at 3:54 AM, Joseph W. [email protected]
wrote:
You can still use non-regular expression steps in Cucumber:
I’ve been unable to think of a good example where I would want only a
partial match of a step. Throwing away the unmatched characters. Does
anyone have good examples where they would?
I think you’ve got this right and exposed a bug. Wanna report it to
lighthouse and/or fix it?
Thanks,
David
David C. wrote:
On Mon, Sep 15, 2008 at 3:54 AM, Joseph W. [email protected]
wrote:
You can still use non-regular expression steps in Cucumber:
I’ve been unable to think of a good example where I would want only a
partial match of a step. Throwing away the unmatched characters. Does
anyone have good examples where they would?
I think you’ve got this right and exposed a bug. Wanna report it to
lighthouse and/or fix it?
Sure I’ll report it and write a patch.
Thanks,
Joseph W.
Thanks,
David
On Mon, Sep 15, 2008 at 3:07 PM, Joseph W. [email protected]
wrote:
lighthouse and/or fix it?
Sure I’ll report it and write a patch.
Hold on.
If you want the regexp to match until the end of the string, why don’t
you just stick a $ at the end of the Regexp?
That’s how regexen work. I don’t see why they should work any
differently when used in Cucumber.
Aslak
On Mon, Sep 15, 2008 at 8:13 AM, aslak hellesoy
[email protected] wrote:
I think you’ve got this right and exposed a bug. Wanna report it to
That’s how regexen work. I don’t see why they should work any
differently when used in Cucumber.
My previous comments withdrawn. I agree with Aslak.
Cheers,
David
On Mon, Sep 15, 2008 at 2:40 PM, David C. [email protected]
wrote:
people think?
Isn’t that what Cucumber does though?
http://github.com/aslakhellesoy/cucumber/tree/master/lib/cucumber/step_mother.rb#L30
(prepending ^ and appending $ to the regexp that’s generated from the
string)
Aslak
On Mon, Sep 15, 2008 at 8:21 AM, David C. [email protected]
wrote:
anyone have good examples where they would?
you just stick a $ at the end of the Regexp?
That’s how regexen work. I don’t see why they should work any
differently when used in Cucumber.
My previous comments withdrawn. I agree with Aslak.
Although, I can see why one might be confused by this. I was. Even
though these are regular expressions, the context led me to an
(erroneous, but intuitive) expectation that in the presence of these
two …
/this and “(.)"/
/this and "(.)” and the other thing/
… that the first would not match “this and that and the other thing”
Perhaps a hint in the error message is in order?
When this and "that" and the other thing
Ambiguous step resolution for "this and \"that\" and the other
thing":
./features//foo-steps.rb:4:in `/this and "(.*)" and the other
thing/’
./features//foo-steps.rb:1:in `/this and “(.*)”/’
(Cucumber::Ambiguous)
Consider ending the shorter expression with a $
WDYT?
On Mon, Sep 15, 2008 at 2:56 PM, David C. [email protected]
wrote:
My intuition would be that if a regular expression did not consume all
Only if you give it a String. Not if you give it a regexp. Unless I’m
missing something (which is entirely possible this fine Monday
morning).
It would be extremely confusing if Cucumber invented its own regexp
matching semantics so that:
/hello/ doesn’t match “hello world”
I’d rather people
a) learn regexp (and write /hello$/)
b) use the string syntax
Or have I completely misunderstood?
Aslak
On Mon, Sep 15, 2008 at 7:49 AM, aslak hellesoy
[email protected] wrote:
regular expression steps in order to minimise surprise conflicts.
(even though it would be in the regular expression domain). What do
people think?
Isn’t that what Cucumber does though?
http://github.com/aslakhellesoy/cucumber/tree/master/lib/cucumber/step_mother.rb#L30
(prepending ^ and appending $ to the regexp that’s generated from the string)
Only if you give it a String. Not if you give it a regexp. Unless I’m
missing something (which is entirely possible this fine Monday
morning).
David C. wrote:
On Mon, Sep 15, 2008 at 8:21 AM, David C. [email protected]
wrote:
anyone have good examples where they would?
you just stick a $ at the end of the Regexp?
That’s how regexen work. I don’t see why they should work any
differently when used in Cucumber.
My previous comments withdrawn. I agree with Aslak.
Although, I can see why one might be confused by this. I was. Even
though these are regular expressions, the context led me to an
(erroneous, but intuitive) expectation that in the presence of these
two …
/this and “(.)"/
/this and "(.)” and the other thing/
… that the first would not match “this and that and the other thing”
Perhaps a hint in the error message is in order?
When this and "that" and the other thing
Ambiguous step resolution for "this and \"that\" and the other
thing":
./features//foo-steps.rb:4:in `/this and "(.*)" and the other
thing/’
./features//foo-steps.rb:1:in `/this and “(.*)”/’
(Cucumber::Ambiguous)
Consider ending the shorter expression with a $
WDYT?
I can see the logic of what you are both saying, so David’s
error/warning seems like the best idea. We can avoid other people
getting confused about this.
–
Joseph W.
http://www.joesniff.co.uk
On Mon, Sep 15, 2008 at 3:27 PM, David C. [email protected]
wrote:
partial match of a step. Throwing away the unmatched characters. Does
If you want the regexp to match until the end of the string, why don’t
two …
./features//foo-steps.rb:4:in `/this and "(.*)" and the other thing/'
./features//foo-steps.rb:1:in `/this and "(.*)"/' (Cucumber::Ambiguous)
Consider ending the shorter expression with a $
WDYT?
I like this much better. -Guiding people to use regexen properly is
better than redefining their semantics.
Feel free to add it.
Aslak
I like this much better. -Guiding people to use regexen properly is
better than redefining their semantics.
Well put. Do you mind if I add this David?
Thanks,
Joseph W.
–
View this message in context:
http://www.nabble.com/Cucumber---Ambiguous-steps-tp19480001p19493430.html
Sent from the rspec-users mailing list archive at Nabble.com.
On Mon, Sep 15, 2008 at 4:00 PM, David C. [email protected]
wrote:
reads:
Multiple step definitions match “Three blind mice”:
./spec/cucumber/step_mother_spec.rb:24:in /Three (.*) mice/' ./spec/cucumber/step_mother_spec.rb:27:in
/Three blind (.*)/’
I think this is a bit more clear than Ambiguous (that reads sorta
funny). Aslak - if you agree, go ahead and pull/merge that commit.
That’s fine.
Aslak