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
Add RSpec/ClassCheck
cop
#1357
Add RSpec/ClassCheck
cop
#1357
Conversation
lib/rubocop/cop/rspec/class_check.rb
Outdated
format( | ||
MSG, | ||
current: node.method_name, | ||
preferred: opposite_method_name(node.method_name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about the following?
preferred: opposite_method_name(node.method_name) | |
preferred: style |
fb3d73b
to
d0e8f67
Compare
43b7e1b
to
93cb479
Compare
93cb479
to
0b10d67
Compare
CI jobs that is failing now is being handled by the following PR Please wait a moment: |
0b10d67
to
86e640e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice addition to our collection of cops. I just had a couple of comments.
.rubocop.yml
Outdated
RSpec/ClassCheck: | ||
Enabled: true | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please move to line 110 or thereabouts.
lib/rubocop/cop/rspec/class_check.rb
Outdated
def autocorrect(corrector, node) | ||
corrector.replace(node.loc.selector, style) | ||
end | ||
|
||
def format_message(node) | ||
format( | ||
MSG, | ||
current: node.method_name, | ||
preferred: style | ||
) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I am directly contradicting @ydah when I say that I don’t like using style
in line 63 and 70. The name of the style and the preferred literal code are incidentally identical, but they are two different concepts. While it’s not a big deal here (we probably won’t change the style names soon) it just doesn’t look right to me.
⬆️ This is just my opinion, not necessarily the truth 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Certainly, you have a point.
One of the reasons I chose to use style
here is that it is better to calculate preferred method names based on style
, rather than based on node
. I think we can probably agree on this point. On top of that, if we want to make it explicit that style and method name are not the same concept, we should put a map from style to preferred method name, even if it seems a bit redundant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that the map would be the best approach. And having it map from style to preferred code (e.g. { be_a: 'be_a', be_kind_of: 'be_kind_of' }
) does seem a bit redundant.
601fb69
to
cea3ae5
Compare
cea3ae5
to
560982f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since there is no restriction on the receiver, only on the method name, such a cop is prone to false positives, e.g. ResponseMock.be_a(sucessful_response)
would be flagged. Even though there is a low chance for people to use such names, it won't hurt to check that the receiver is nil
|
||
context 'when enforced style is be_kind_of and be_kind_of is used' do | ||
let(:cop_config) do | ||
{ 'EnforcedStyle' => 'be_kind_of' } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather organize the spec in two top level contexts (by the enforced style) and then have examples for the usages; thus avoiding the repetition in cop_config
560982f
to
6544044
Compare
let(:cop_config) do | ||
{ 'EnforcedStyle' => 'be_kind_of' } | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can move this config in the parent context, so you don't need to repeat it in the next ones
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, I forgot to move them. Thank you! 👍
6544044
to
d9f1335
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you
@@ -106,6 +106,8 @@ RSpec/BeNil: | |||
Enabled: true | |||
RSpec/ChangeByZero: | |||
Enabled: true | |||
RSpec/ClassCheck: | |||
Enabled: true |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
It would be nice to have a new cop similar to the
Style/ClassCheck
cop.Before submitting the PR make sure the following are checked:
master
(if not - rebase it).CHANGELOG.md
if the new code introduces user-observable changes.bundle exec rake
) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).If you have created a new cop:
config/default.yml
.Enabled: pending
inconfig/default.yml
.Enabled: true
in.rubocop.yml
.VersionAdded
indefault/config.yml
to the next minor version.If you have modified an existing cop's configuration options:
VersionChanged
inconfig/default.yml
to the next major version.