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

Not enable RSpec/LetSetup by default #887

Closed
goodniceweb opened this issue Mar 26, 2020 · 4 comments
Closed

Not enable RSpec/LetSetup by default #887

goodniceweb opened this issue Mar 26, 2020 · 4 comments

Comments

@goodniceweb
Copy link

My first issue here I want to start with words of thankfulness: this project helped me write better rspec tests. Big thanks to all members and contributors!

Talking about the issue: RSpec/LetSetup. Across multiple projects I face the same issue: we keep removing this rule. That's why I open this issue, just because I think I'm not the only person in the world who does it.

Considering all those examples and official documentation I'd ask to make this code disabled by default.

goodniceweb added a commit to goodniceweb/rubocop-rspec that referenced this issue Mar 26, 2020
goodniceweb added a commit to goodniceweb/rubocop-rspec that referenced this issue Mar 26, 2020
goodniceweb added a commit to goodniceweb/rubocop-rspec that referenced this issue Mar 26, 2020
@bquorning
Copy link
Collaborator

bquorning commented Mar 26, 2020

This seems like a duplicate of #94, and I still stand by my response there, which quotes one of the RSpec maintainers:

I find before and let to be useful for particular situations, but find that they often get mis-used/abused in the wild, unfortunately. My rule of thumb is to use them when there's a compelling benefit, but don't reach for them as the default way to write specs.

betterspecs.org is not the official documentation. The official documentation has no recommendation for or against using let!.

I am curious to know which specs you have that cannot be written without using let!?

@pirj
Copy link
Member

pirj commented Mar 26, 2020

words of thankfulness: this project helped me write better rspec tests. Big thanks to all members and contributors!

Thank you!

Can you find proof across real-world-ruby-apps and real-world-rails that for projects that use RSpec that the cop in question is disabled significantly more often than not?

rubocop-rspec is configurable, and we encourage people to tune the configuration to fit the style established in their projects. We should probably emphasize that just like our parent project, rubocop does:

is extremely flexible and most aspects of its behavior can be tweaked via various configuration options.

The defaults of rubocop-rspec tend to be normalized with the community-driven RSpec style guide, while usually rubocop-rspec provides a superset of what the style guide recommends.

RuboCop's version and cop enablement policy states that the cops will be enabled on major versions, and the exception to this would only be cops that are really rarely used and not used by many. Other cops, even possibly mutually exclusive, will be enabled, with some default enforced styles.
On minor version changes, when new cops will be introduced, or enforced styles will be changed, you will have to explicitly enable or disable such cops.
Yes, that probably means your .rubocop.yml will grow big, but that also means that it's you who's in control, not those who maintain RuboCop or its extensions.

The defaults are carefully picked in such a way that they make sure the code is consistent, gotcha-free, and canonical.

I'm not getting into the discussion if let! is canonical or not, I must admit I have a bias here, so let's see what the numbers say. Your call @goodniceweb.

@pirj
Copy link
Member

pirj commented Apr 3, 2020

Please feel free to reopen if there's some evidence that RSpec/LetSetup is in general disabled more often than not.

@pirj pirj closed this as completed Apr 3, 2020
@ioquatix
Copy link

ioquatix commented Jan 5, 2021

I also agree with the OP.

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

4 participants