Improve RSpec/SubjectStub cop

[pirj]

1. Use consistent wording in docstrings

2. Improve stub detection

Previously, the following code would still be detected as an offence:

allow(subject)

even though there are no message expectations.

3. Add detection of negated runners (not_to, to_not) - fixes #705

4. Add support for chain and multiple stub detection (receive_messages, receive_message_chain)

5. Add more reasoning references

6. Improve offence message

7. Remove special case all matcher (see #488)

This special case treatment was added to address one use case, of an object that acts as a container for and a delegator of method calls to containing items by inheriting from an Array.

The original code that suffered from a false detection was:

expect(formatter_set).to all(receive(:started).with(files))
formatter_set.started(files)

However, it has been reworked to:

  formatter_set.each do |formatter|
    allow(formatter).to receive(:started)
  end
  formatter_set.started(files)
  expect(formatter_set).to all(have_received(:started).with(files))

and can be further simplified to:

formatter_set.each do |formatter|
  expect(formatter).to receive(:started).with(files)
end
formatter_set.started(files)

which in case of this specific object design is more indicative of what happens.

8. Added support for have_received detection, to detect the bad code above.

9. Fixed detection of the unnamed subject stubbing when the subject is named.

Fixes #705

---

Before submitting the PR make sure the following are checked:

• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Added an entry to the changelog if the new code introduces user-observable changes.
• The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

[bquorning]

I’m not sure I understand the case for removing the all matcher. Yes, it was implemented after just a single bug report, but that doesn’t mean there are not more examples out there. I assume – since RSpec allows it – that they are valid use cases.

Or is the code removed unnecessarily complex?

I just need a bit more clarification on why we should remove this feature.

[pirj]

I'm sorry, but I disagree that if RSpec allows something, it's a valid (correct) use case. rubocop-rspec wouldn't have existed then. Did I understand your statement correctly at all?

As an experiment, I've run a modified version of this cop that only detects expect(subject).to all receive(...) (along with not_to, have_received etc) against real-world-ruby-apps (11k files) and real-world-rails (79k files).
The result is that there was no single offence for the cop.

PS Analysis of the latest rubocop (real-world-ruby-apps seem to point to an older version):

spec/rubocop/formatter/formatter_set_spec.rb:27:7: C: RSpec/SubjectStub: Do not stub methods of the object under test.
      expect(formatter_set).to all(have_received(:started).with(files))
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I don't have a strong opinion if this special all case should be removed or kept.

What do you think?

[pirj]

Tried simplifying that spec on RuboCop side, and it turns out another cop, RSpec/MessageSpies, starts complaining that receive is used instead of have_received. What confuses me is that according to the chat from 10 Oct 2016:

If a spec example has multiple stubs (allow) and you want a focused spec with just one expectation per example – and RuboCop is now telling you that you must change all those stubs into expectations. Not good.

However, in rubocop this is not a problem, as multiple expectations per example are allowed:

RSpec/MultipleExpectations:
  Max: 25

I'll try my chances with changing the enforced style for MessageSpies to receive, and fixing that lonely example.

Would you accept this pull request with the removal of all special case if those two are accepted?

[pirj]

One last known use case for expect(...).to all receive has been fixed.

I'll be more than happy to bring all exclusion back in case someone complains about it, please feel free to assign the ticket to me when this comes up.

Is there anything else left to be addressed in this pull request?

[pirj]

Is there anything else how I can improve this?

[pirj]

@bquorning @Darhazer I've sent a pull request that would quickly restore the all special case.

In case of emergency, it can be immediately merged.

Do you have some other doubts regarding the changes made in this pull request?

[pirj]

@bquorning @Darhazer Is there anything else that needs to be addressed in this pull request?

[bquorning]

Hi @pirj, apologies for the slow response rate around here. Your PR is in my review queue, but I just haven’t had time to get a good look at it yet.

[pirj]

No worries, please take your time.

[pirj]

@bquorning I was considering this, but haven't found any other cop that would benefit from it immediately. Probably there are some missed cases due to this in the other cops, but I can't tell that off the top of my head.

[pirj]

Please don't merge this just now, @Darhazer has found a case this cop is missing, flagging of an unnamed subject (expect(subject).to receive). Will address this quickly.

[pirj]

Fixed.

[bquorning]

I expect the failing circleci job (codeclimate) to pass on master.

[bquorning]

Thank you for the contributions, persistence, and patience 😄

[pirj]

Thanks for accepting @bquorning, @Darhazer!