-
-
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
Handle dynamic mocks specially for null-object doubles #1455
Handle dynamic mocks specially for null-object doubles #1455
Conversation
Specifically, when applying these dynamic matchers to a spy, only consider them to have the method in question if it's explicitly defined on the double; don't let the null-object double pretend.
This should short-circuit a common mistake, where someone typos expect(my_spy).to have_receivedd(:foo) and gets an evergreen test, because strict_predicate_matchers is disabled, and null-object spies return a truthy value (themselves) when asked `has_receivedd?`.
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.
Looks mostly good, thanks for the fix!
Wondering why we don’t print them 🧐 |
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.
Can you please use our fail matcher in the specs
Thank you! This was so ugly, I should have known there would be a matcher for that :-D |
BasicObjects don't even have `is_a?` (or `class`, or `===`, etc), so the only way I see to behave correctly for that case is to _try_ to check if they're a Double, and also handle `NoMethodError` with "Oh, you're that basic? Not a Double then."
.. BasicObject doesn't have I'm not sure how to safely detect that I'm dealing with a BasicObject though, since it doesn't have Any advice? I could just catch NoMethodError on (I think the current changes pass the tests, I just don't love using error-handling for this kind of thing unless it's actually necessary) |
Oh, and please let me know if I'm using PRs wrong here - I've run into a variety of expectations regarding who resolves conversations, how much feedback to ask for, etc. You guys seem super-active, so I'm hoping I can be helpful. |
No worries on the code, it feels that we’re getting along quite good. Thanks for your tireless contributions! |
Darn, looks like I still have some kind of problem on ruby-1.8.7. I've never actually gotten it to install on an m1, guess I'll spend some time on that today. It's obviously going to keep coming up :-) |
Luckily, we already have some code in this very file that handles that situation, so we can just ride along.
7a56da1
to
5cf5ad3
Compare
Much nicer, and using === instead of is_a? also saves us the rescue clause!
Thank you! |
…hes-on-mocks-specially Handle dynamic mocks specially for null-object doubles
Released in 3.13.2 |
This hopefully resolves #1132 and #1288 - essentially, if you leave
strict_predicate_matchers
disabled and use a null-object spy like this:It'll pass. Note the typo in
have_receivedd
? The dynamic matcher will callhas_receivedd?
on the spy, the spy will return itself (that's what it does), and the matcher will note that the result is truthy, and pass the spec. That's kind of an issue - turning off that setting does solve it, but that won't be the default until rspec 4, and even then it's not the ideal behavior, just a lot better.This PR updates the dynamic matchers to notice when their target is a Double, and change behavior slightly - for Doubles, don't just check if they respond to the method, also check if it's in the
methods
list. That'll suffice to confirm that it's explicitly mocked on the double, rather than being an automatic response.