You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think that cop is useful: expectations belong in it or specify blocks, not in before or after hooks. imho the pattern when you stub a method but want to assert that the method is called, should be like this (even at the cost of duplication):
# ↓ before block, or inside exampleallow(obj).toreceive(:foo).and_return(:bar)# ↓ inside exampleexpect(obj).tohave_received(:foo)
because we also have only one expect per spec
I think ↑ that is the cop that is more harmful than useful. It appears to be less strict in loveos-backend, where 2 expects are allowed per example. My vote is to turn off RSpec/MultipleExpectations altogether and rely on people’s best judgment not to put 100 expects into one it (but even that can in rare cases be acceptable, e.g. in a loop?)
I don't like ExpectInHook
I think it is useful to setup something like:
before { expect(obj).to receive(:foo) }
The laziest solution, because we also have only one
expect
per spec, is to change it to:before { allow(obj).to receive(:foo) }
But this weakens the test requirements, which should not be an effect of rubocop.
The text was updated successfully, but these errors were encountered: