Prefer spies over mocks

[andyw8]

I think a cop to verify that spies are used instead of stubs would be useful.

See http://robots.thoughtbot.com/spy-vs-spy

I'll try writing a PR for this if you agree with the principle.

[geniou]

I like the idea. I'm not sure if this cop can be enabled by default, but I would add it the the selection. So feel free to add a pull request.

[backus]

I think the best way for this to work as a cop is to use the EnforcedStyle convention rubocop has and just help enforce consistency (basically this gem shouldn't tell people whether to use spies or mocks). Essentially this should boil down to:

Prefer mocks

RSpec/MessageExpectation:
  EnforcedStyle: expect

Prefer spies

RSpec/MessageExpectation:
  EnforcedStyle: allow

[backus]

@geniou I've implemented this (#169) and I think it can be enabled by default. The cop supports EnforcedStyle and works with --auto-gen-config. Basically, if someone has inconsistent usage, --auto-gen-config can disable the cop in the user's .rubocop_todo.yml file.

[geniou]

OK. Looking forward to see it in action. I'm not convinced that there is always only allow or expect - I think both have there use case, but I'll give it a try.

[jcoyne]

I'm very disappointed to see this go in. When I want rspec to check something I use expect, but if I need an unchecked mock, I use allow. They are two different use cases.

[backus]

@jcoyne I'm happy to take your input on cops and even improve them if you think they are lacking. It is difficult to work with you though when your opening comments, without asking any questions about why we put time into these cops, are so negative.

[jcoyne]

I'm sorry for being negative. It's a bitter pill to swallow when I update my bundle and all the builds start failing.

[backus]

@jcoyne thanks for apologizing. Likewise, you can imagine it being unpleasant to see these comments out of no where when I just try to add helpful cops in my free time.

With this all said, are you dead set on moving forward with your "Abandon rubocop-rspec" PR you've linked above or would you like me to continue to share context for these other cops? They are all implemented to be configurable and adjust to the user's preference. I'm happy to elaborate later if you're interested but I don't want to waste my time if you've written off this gem

[jcoyne]

@backus I'm probably going to abandon rubocop-rspec on that one project, but I have at least a dozen projects that use it. (which is why changes are painful)

[backus]

@jcoyne that makes sense. You should look into rolling a gem that just has your shared rubocop configuration in it and also a rubocop + rubocop-rspec dependency. Then you could use rubocop's inherit_gem feature for inheriting shared config and then you would also not have as much of a problem of having surprise failures if you are only ever bumping the version of your rubocop dependency gem

[backus]

@jcoyne Glad to see you ended up sticking with the gem :) samvera/hyku#298

[jcoyne]

@backus Yeah, tired and cranky last night ☺️ I'm better now.

[bquorning]

@jcoyne In #224 I’m rewriting the MessageExpectation cop to police receive vs have_received instead of policing allow vs expect. Your feedback would be much appreciated.

[jcoyne]

@bquorning I like that (#224)!