-
-
Notifications
You must be signed in to change notification settings - Fork 276
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
RSpec/StubbedMock false positive #1518
Comments
Thanks for reporting! It is pretty legitimate to use it to verify arguments. Even though the doc suggests using I'd propose ignoring the block form if it captures arguments. Would you like to submit a PR, @ngouy ? |
@pirj Thanks for confirming! (so fast 🏎️ 💨 ) Maybe we could ignore as long as we don't call Also I could try, it won't be before 2023. things are getting busy for OEY (as anyone else anyway I guess) |
Even though we have On the other hand, if the block form captures arguments, we can assume that the block is used to verify arguments, not to stub the response. |
So what is your directive? |
The AST difference is: receive(:foo) { bar }
receive(:foo) { |x| bar }
The node matcher is:
And what we need is to teach it to make a distinction between no block As a last touch, add an example that would show that we ignore message expectations with a block that accepts arguments here. |
…ectation with a block and block parameter Fix: rubocop#1518
…ectation with a block and block parameter Fix: rubocop/rubocop-rspec#1518
…ectation with a block and block parameter Fix: rubocop/rubocop-rspec#1518
…ectation with a block and block parameter Fix: rubocop/rubocop-rspec#1518
I have a case where I want to play more extensively with the arguments that are passed to a call
I don't stubb the return value at all
Yet it is suggested I use
allow
overexpect
which really is out of question given I absolutely want to know if the method was called, with specific argsThe text was updated successfully, but these errors were encountered: