-
-
Notifications
You must be signed in to change notification settings - Fork 359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Combine 'any instance' cukes #398
Conversation
Thanks for taking initiative on this, @soulcutter. Long term, I'm thinking I'd rather the cukes use the new syntax consistently everywhere, and then we can have on cuke file that demonstrates usage of the old syntax (but doesn't show every last feature of it). Do you think it makes sense to move in that direction now? |
Yeah, now is probably the time to start that conversion. What are we calling the old syntax anyway? monkey-patched? extended Object? old?.. Argh, looks like my merge was not quite right either. 😕 |
We discussed several options in #266. Originally I was going to call the syntaxes |
|
||
it "verifies that one instance of the class receives the message" do | ||
o = Object.new | ||
o.foo.should eq(:return_value) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use expect
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 especially give you're setting the expectation with the new syntax
Combine 'any instance' cukes
Thanks, @soulcutter! |
expect_any_instance_of.feature
andany_instance.feature
both have the same Feature description, which makes navigating relish app confusing:To resolve this, I combined those files.
Additionally I would like to pose the question of whether it makes sense to combine
message_expectations/allow_any_instance_of.feature
withmethod_stubs/any_instance.feature
?