-
-
Notifications
You must be signed in to change notification settings - Fork 358
Document receive(:msg).with(satisfy{|arg| ... }) #1477
Conversation
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.
We're happy to improve documentation here, I've a bit of feedback for the scenario.
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.
Thank you!
before do | ||
expectation = satisfy do |data| | ||
data[:a][:b][:c] == 5 | ||
end | ||
expect(dbl).to receive(:foo).with(expectation) | ||
end | ||
|
||
it "passes when the expectation is true" do | ||
dbl.foo(a: { b: { c: 5 } }) | ||
end | ||
|
||
it "fails when the expectation is false" do | ||
dbl.foo(a: { b: { c: 3 } }) | ||
end |
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.
It is very subjective, but I would argue about this example's style. Firstly, the expectation is made in a hook.
The term expectation
from my perspective is used incorrectly, the satisfy
matcher is used as an argument matcher here.
How do you feel about this instead:
RSpec.describe "Using satisfy for complex custom expecations" do
let(:dbl) { double }
def a_b_c_equals_5
satisfy { |data| data[:a][:b][:c] == 5 }
end
it "passes when the expectation is true" do
expect(dbl).to receive(:foo).with(a_b_c_equals_5)
dbl.foo(a: { b: { c: 5 } })
end
it "fails when the expectation is false" do
expect(dbl).to receive(:foo).with(a_b_c_equals_5)
dbl.foo(a: { b: { c: 3 } })
end
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.
It is very subjective, but I would argue about this example's style. Firstly, the expectation is made in a hook.
...
How do you feel about this instead:
I followed the style of other stories in this file, but I like yours better, so I adopted your suggestion.
The term
expectation
from my perspective is used incorrectly, thesatisfy
matcher is used as an argument matcher here.
As I understand it, the goal is to verify an expectation. The mechanism is to use a matcher. If I've mixed things up, or if you want to emphasise one or the other in the documentation, let me know what changes you'd like to see.
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.
Thank you!
ea0fb01
to
898cdaa
Compare
cucumber/cucumber-expressions#272 cucumber/cucumber-expressions#273 for ruby-head Something weird is wrong with 3.2, IDK For 1.8.7 the failure diff is + expected: (satisfy block)
-expected: (satisfy expression `data[:a][:b][:c] == 5`) which is due to the lack of Ripper in Ruby < 1.9.2 . |
The Ruby 3.2 rspec-core related failure reproduced in a rspec/rspec-core#3046 build, so I intend to fix it there. @tjallingvanderwal Thank you for this nice doc addition! Please accept my apologies for the long processing. |
No apologies needed. Thank you for finishing my pull request. |
Document receive(:msg).with(satisfy{|arg| ... })
This is the combination I've been looking for, but that has eluded me for years.
The readme and the table in the relish docs both mention that any matcher can be used, but it never occurred to me to combine
with
withsatisfy
.I've added 2 example usages to the readme and added a Cucumber story to document this combination.
The documentation for
satisfy
suggest to write a custom matcher, but that feels over the top for many one-off situations.