Don’t stub when you’re mocking

[bquorning]

Fixes #221.

TODO

• Must also work for and_raise, and_yield, and_throw, and_call_original, and and_wrap_original.
• Changelog entry.
• Rename cop?
• Better cop description.

cc @backus

If you have created a new cop:

• Added the new cop to config/default.yml.
• The cop documents examples of good and bad code.
• The tests assert both that bad code is reported and that good code is not reported.
• Set VersionAdded in default/config.yml to the next minor version.

[backus]

@bquorning I played with the branch locally to get the highlighting you are interested in. This should work:

diff --git i/lib/rubocop/cop/rspec/mock_not_stub.rb w/lib/rubocop/cop/rspec/mock_not_stub.rb
index 286df07..aba2985 100644
--- i/lib/rubocop/cop/rspec/mock_not_stub.rb
+++ w/lib/rubocop/cop/rspec/mock_not_stub.rb
@@ -27,8 +27,8 @@ module RuboCop
           (send
             (send nil :expect ...) :to
             {
-              (send #receive :and_return $_)
-              (block #receive (args) $_)
+              $(send #receive :and_return _)
+              $(block #receive (args) _)
             }
           )
         PATTERN
@@ -42,7 +42,24 @@ module RuboCop

         def on_send(node)
           message_expectation_with_return_block(node) do |match|
-            add_offense(match, :expression)
+            source_map = match.loc
+
+            offending_range =
+              if match.send_type?
+                Parser::Source::Range.new(
+                  source_map.expression.source_buffer,
+                  source_map.selector.begin_pos,
+                  source_map.end.end_pos
+                )
+              else
+                Parser::Source::Range.new(
+                  source_map.expression.source_buffer,
+                  source_map.begin.begin_pos,
+                  source_map.end.end_pos
+                )
+              end
+
+            add_offense(match, offending_range)
           end
         end
       end

I'd refactor it a bit of course to make it not just one big method.

[backus]

Nice job with the node pattern stuff btw. I wish people would use it more on rubocop proper

[bquorning]

Thanks for the code snippet there, @backus. I think I’ll use source_map.dot.begin_pos instead of source_map.selector.begin_pos and get highlight on the . preceding and_return as well.

[backus]

Should this cop be configurable? It seems like expect(...).to receive(...).and_return(...) should be a valid style.

[bquorning]

Configurable? You can just disable it. Perhaps I misunderstand you?

[backus]

No I guess I was curious if there was an alternate style that this sort of thing could also enforce if we're just saying "do not use this part of the RSpec API."

I look forward to hearing outside input for @jcoyne. I'm wondering how users will respond to this cop.

[backus]

Should this cop also reject things like expect(...).to receive(...).and_raise(...), expect(...).to receive(...).and_yield(...), expect(...).to receive(...).and_throw(...)?

[bquorning]

Should this cop also reject things like …

Yes, good point. All three cases should be policed by this cop.

[bquorning]

Also and_call_original, and_wrap_original, yield_with_args…

[jcoyne]

Can you say why this is good style? What's the justification?

[bquorning]

The argumentation / justification is in #221.

[jcoyne]

It sounds like you want to change the rspec-mocks API via rubocop. Have you considered this change as a deprecation in rspec-mocks?

[bquorning]

Have you considered this change as a deprecation in rspec-mocks?

Yes :-) I thought it would be easier to start here.

I’ve also considered mentioning someone from rspec-mocks in this PR.

[jcoyne]

@bquorning I think that would be a good idea. If you want to influence the usage of a library, it makes sense to consult the authors thereof.

[bquorning]

After a brief discussion in rspec/rspec-mocks#1123 I’m convinced that rspec-mocks will not change its DSL. Which makes this a personal style preference – perhaps suitable for RuboCop-RSpec?

[backus]

@JonRowe would you consider deprecating this behavior?

Maybe if there was a broad community consensus. But users like to use different parts of RSpec in different ways and I would expect a lot of push back on such a deprecation. In general, we don't deprecate or disallow things just because something is a code smell.

I think seeing myron call this a code smell is more than enough to convince me that this is worth making a cop

[backus]

I'll try to do another review tonight

[JonRowe]

Just a personal opinion (which may or may not be shared with my other rspec team members) but this cop should be disabled by default it's very much a personal opinion that creates extra code for people, and rubocop tends to give the impression that something is "recommended best practise" which this isn't.

[backus]

@JonRowe thanks I'll keep that in mind. If you have a minute, would you be able to look at the other cops and say whether you think this is true for the others? I'm curious how broad you view things as style vs. best practice.

On an unrelated note, I'm not sure how much rubocop is "recommended best practice" anymore given that most cops with more than one possible style tend to be configurable in different ways.

[JonRowe]

On an unrelated note, I'm not sure how much rubocop is "recommended best practice" anymore given that most cops with more than one possible style tend to be configurable in different ways.

I see people using the default config a fair bit, and just accepting them as "the way"

[pirj]

Looks good.

[dgollahon]

I kind of lean with the disable-by-default crowd here. This feels a little obscure/confusing to me, though @bquorning motivating example in the linked issue seems reasonable and I would probably write the specs the same way he would. I strongly suspect we'll get very confused users asking what we mean by this cop though and why it's better to do it another way, so my intuition is that it's a little too surgical for the average user.

If this gets merged and enabled by default, the explanation/motivation should probably be documented more clearly, imo.

[pirj]

@Darhazer @bquorning Rebased, ready for reviews. If you have objections to merging this, please speak up.

[pirj]

Even though it's your own pull request, I'd love to hear your thoughts on the recent changes before merging it @bquorning

[bquorning]

Maybe I’m having a bad day, but I have a really hard time understanding this code. It’s not immediately obvious what the node matchers actually match. The names are easy enough to understand (maybe except matcher_with_blockpass_or_hash which I’m not sure I get), but… Maybe we should start adding adding comments to our node matchers, with one or two examples of what the would match?

It can also be that I lack training in reading node patterns (and parser output). I wonder how others feel about this?

[pirj]

Thanks for this fresh view on the cop.
It's quite common to miss the complexity when working on it, but as time goes, this complexity becomes apparent.

In addition to node matcher YARD docs that I believe now help a lot to understand RSpec/EmptyExampleGroup's node patterns, there's also Node pattern comment feature.
I intend to add both to this cop's node patterns.

[bquorning]

Even though it's your own pull request, I'd love to hear your thoughts on the recent changes before merging it @bquorning

Absolutely. Sorry for sometimes taking several days before responding; it feels like there are fewer hours in a day than there used to be 😕

Perhaps the spec for pending state can stand alone, but you can squash the other commits (just change me to be co-author).

[pirj]

That's kind of odd that LineLength ignores HEREDOC

[pirj]

Wondering if you guys find that kind of node pattern comments helpful @bquorning @Darhazer

[bquorning]

I found them very useful, thank you @pirj

[marcandre]

# bad
expect(foo).to receive(:bar).with(42).and_return("hello world")
# good (without spies)
allow(foo).to receive(:bar).with(42).and_return("hello world")
expect(foo).to receive(:bar).with(42)

I strongly disagree that an expressive and DRY form should be broken into two repetitive forms for no benefit. I would support a cop that does the reverse.

I really dislike when cops complain about valid code, especially when the solution is not clearly better (i.e. clearly worse for many, me included).

Of course, I fully realize that yes, we can disable it. That mere fact does not imply that the cop should be enabled by default.

I believe having cops like these, enabled by default, give RuboCop a bad name.

Note: I'm sorry, I didn't read the whole thread as it contains comments on the code as well as discussion about the usefulness of the cop itself. I'll just comment on this:

I think seeing myron call this a code smell is more than enough to convince me that this is worth making a cop

He did not specifically call this a code smell (and I would disagree with him if he did)

[bquorning]

There has been a lot of discussion for and against whether this cop should be enabled by default. I am actually not sure if we really made any decision either way.

@pirj I remember you revived this PR in #226 (comment), but I do not recall if we really decided to let this cop be enabled or disabled by default. I think it just … happened.

[marcandre]

I think it just … happened.

Maybe disabling it and issuing a 2.0.1 release is the way to go then.

[pirj]

@marcandre

~/source/rubocop $ rubocop --only RSpec/StubbedMock

Offenses:

spec/rubocop/result_cache_spec.rb:178:11: C: RSpec/StubbedMock: Prefer allow over expect when configuring a response.
          expect(team).to(
          ^^^^^^^^^^^^
spec/rubocop/result_cache_spec.rb:191:11: C: RSpec/StubbedMock: Prefer allow over expect when configuring a response.
          expect(team).to(
          ^^^^^^^^^^^^
spec/rubocop/result_cache_spec.rb:332:9: C: RSpec/StubbedMock: Prefer allow over expect when configuring a response.
        expect(FileUtils).to receive(:mkdir_p).with(start_with(cache_root))
        ^^^^^^^^^^^^^^^^^

... 3 offenses detected

Let's take a closer look:

      context 'when team external_dependency_checksum changes' do
        it 'is invalid' do
          cache.save(offenses)
          expect(team).to(
            receive(:external_dependency_checksum).and_return('bar')
          )
          cache2 = described_class.new(
            file, team, options, config_store, cache_root
          )
          expect(cache2.valid?).to eq(false)
        end
      end

If I would be reading this, I would ask myself:

1. Why is expect(team) an expect and not allow, is there a risk that the SUT won't send an external_dependency_checksum message to team?
2. Why, if we have:

• properly balanced examples
• we check the output

we didn't limit ourselves to set the input and rather decided to increase specs' brittleness by tying ourselves to the internal implementation?

You may also notice that:

  before do
    #...
    allow(team).to receive(:external_dependency_checksum).and_return('foo')`

This means we're double-stubbing external_dependency_checksum 😱
We should have received RSpec's:

            "You're overriding a previous stub implementation of `#{@message}`. " \
            "Called from #{CallerFilter.first_non_rspec_line}."

warning, but we don't, not sure why exactly, probably because it's only implemented for pure doubles and doesn't work on partial doubles, or warnings are muted somehow.

The fact that this spec works doesn't mean it's good. I can lend you a hand with fixing it and turning StubbedMock back to Enabled: true if you like.

I don't have other specs on hand to reason about, but I'm all ears to know when RSpec/StubbedMock doesn't make sense at all.

[marcandre]

we're double-stubbing external_dependency_checksum

The first allow is called once to build the cache, then the method is stubbed again for the second call to check the cache validity.

increase specs' brittleness

The spec assumes an implementation detail. If that implementation detail, the spec needs to be changed. That's why we stub only when there is no better alternative. I see the spec failing as a virtue.

Other remarks in rubocop/rubocop#9006

[pirj]

Just for the record, I take back my argument that double-stubbing is an offence, it's my false belief.