-
-
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
StubbedMock: prefer expect
#1061
Comments
I understand what you mean, this in the best case renders this a = []
allow(a).to receive(:[]).with(1).and_return(2)
expect(a).to receive(:[]).with(1)
expect(a[1]).to eq 2 This makes me feel somewhat uncomfortable though, as it binds the implementation to the spec. |
FWIW, we've defined an expect { a[1] }
.to invoke(:[]).on(a).with(1).and_return(2) Though, like you say, we wouldn't normally test both the return value and the call. We'd normally avoid mocking at all, if we can reasonably. |
|
Just upgraded and came across the new
StubbedMock
rule. I'd love to have a configuration that inverts the rule and prefersexpect
overallow
. The reason for this is that I often come across tests where the implementation in the application code has changed such that the method is never called. I would rather have these cases fail the tests so that we also remember to remove the irrelevant mock from the tests.The text was updated successfully, but these errors were encountered: