Skip to content
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

Open
mockdeep opened this issue Oct 24, 2020 · 3 comments
Open

StubbedMock: prefer expect #1061

mockdeep opened this issue Oct 24, 2020 · 3 comments

Comments

@mockdeep
Copy link
Contributor

Just upgraded and came across the new StubbedMock rule. I'd love to have a configuration that inverts the rule and prefers expect over allow. 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.

@pirj
Copy link
Member

pirj commented Oct 26, 2020

I understand what you mean, this in the best case renders this allow line useless.
For those specs that have do depend on the internal implementation, I guess allow+expect is the way to go:

    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.
From my point of view, it should either make an expectation on the result (what), or side effects (how), not both.

@mockdeep
Copy link
Contributor Author

FWIW, we've defined an invoke matcher that captures this as well:

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.

@pirj
Copy link
Member

pirj commented Nov 2, 2020

invoke 👍
There's a comparable send_message just in case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants