-
-
Notifications
You must be signed in to change notification settings - Fork 395
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
Unexpected target/handler behavior with respect to blocks #536
Comments
Right now, the decision of whether to call the incoming "actual" value as a proc is left up to the specific matcher ( |
Try master (soon to be released on 3.0.0.rc1) and see if that meets your needs. |
I'm so bummed I missed the conversation! It seems like the responsibility of interpreting user intent has been put on the matcher, when the expectation target has the distinct ability to differentiate a block and a proc argument. But you've already had lengthy conversation about this, so I'll defer to the group wisdom rather than beat a 💀 🐴. Thank you for the quick reply! |
The matcher has no idea of user intent: it just indicates whether or not the creator of the matcher intends it to be usable in a block expectation expression. If the creator of the matcher does not intend that usage, than passing
The expectation target does differentiate a block vs a proc: Note that one complexity of this (that's subtle) is that it's essentially impossible to make an expectation expression like |
Might the |
It could, but we'd rather not support that use case, there's no advantage in passing a block to |
It's never been something we've supported and I don't see a reason to start. IMO, it will cause more confusion...if we supported that, it would suggest to the user that passing an arg vs a block are equivalent, since this would then work: expect(3).to eq(3)
expect { 3 }.to eq(3) ...but this wouldn't: expect { do_something }.to raise_error
expect(do_something).to raise_error I think that to use the block expectation matchers properly, it's important for users to understand that what they are matching on can't be represented as a simple value, and your suggestion makes it harder to understand that. |
Thank you for the feedback. I have a better understanding of your approach now. Good luck with 3.0! |
expect { do_something }.to raise_error That above code works fine form me. For an example: expect { begin MultiJson.load('{invalid json}') rescue MultiJson::ParseError => exception exception.data # => "{invalid json}" exception.cause # => JSON::ParserError: 795: unexpected token at '{invalid json}' end }.to raise_error |
How does one get the rspec matcher to implement |
Just define it as a method inside your matcher definition, e.g. class MyMatcher
def supports_block_expectations?
true
end
# ...
end If you are using the matcher definition DSL, you can just call RSpec::Matchers.define :my_matcher do
supports_block_expectations
# ..
end |
hi @myronmarston , thanks for the reply - I'm fairly new to Ruby and rspec. I really appreciate the helpful info! |
@myronmarston, thanks for the fix, though
is a really confusing message. It made me think |
@NickTime what is your code snippet that generated that message? |
@myronmarston https://github.com/nicktime/tomograph/blob/add-json-support/spec/lib/tomograph/api_blueprint/yaml_spec.rb#L70
So I was thinking the problem is with |
Do you have a suggested wording improvement? It means |
I'd suggest
Confusion is only about which method it is that can't take a block, otherwise message is clear. |
Good improvement, would you like to tackle it in a PR? |
If it's just updating text then yes, here it is #1066 |
Thanks :) |
I would expect the following two assertions to behave similarly, at least to the point that they would both pass, but they don't.
In the same vein, I would expect these two assertions to behave differently but they are identical.
It seems that the handoff between the target and the handler could be improved by somehow providing context/insight into whether the incoming "actual" value is something dynamic to be evaluated (a given block) or a static value (even a proc) given as an argument.
I'm hoping it's worth a conversation. Thank you!
The text was updated successfully, but these errors were encountered: