Add custom RuboCop for assert_not over refute
#32441
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @kaspth (@rails-bot has picked a reviewer for you, use r? to override) |
Did you actually meant to write "we have preferred assert_not over refute"? |
|
Yes! ACK! |
Since at least cf4afc4 we have preferred `assert_not` methods over `refute` methods. I have seen plenty of comments in PRs about this, and we have tried to fix it a few times (5294ad8, e45f176, 8910f12, 41f50be, d4cfd54, 48a183e, and 211adb4), but the `refute` methods keep sneaking back in. This custom RuboCop will take care of enforcing this preference, so we don't have to think about it again. I suspect there are other similar stylistic preferences that could be solved with some custom RuboCops, so I will definitely keep my eyes open. `assert_not` over `assert !` might be a good candidate, for example. I wasn't totally sure if `ci/custom_cops` was the best place to put this, but nothing else seemed quite right. At one point I had it set up as a gem, but I think custom cops like this would have limited value in another context. I want to see how code climate handles the new cops before autocorrecting the existing violations. If things go as expected, I will push another commit with those corrections.
73e7aab behaved as expected on codeship, failing the build with exactly these RuboCop violations. Hopefully `rubocop -a` will have been enough to get a passing build!
composerinteralia
force-pushed
the
refute-not
branch
from
0fdf1b0
to
c1ceafc
Compare
|
cc @toshimaru |
koic
added a commit
to koic/rubocop-rails-style
that referenced
this pull request
Apr 8, 2018
This PR backports rails/rails#32441. IMO, I think that it would be more plausible to write `require: rubocop-rails` instead of `require: custom_cops` in config/rails.yml, but first of all this PR writes `require: custom_cops` according to upstream.
koic
added a commit
to koic/rubocop-rails-style
that referenced
this pull request
Apr 8, 2018
This PR imports rails/rails#32441. IMO, I think that it would be more plausible to write `require: rubocop-rails` instead of `require: custom_cops` in config/rails.yml, but first of all this PR writes `require: custom_cops` according to upstream.
|
I think this cop has a useful opportunity in Rails applications. Therefore I will export this cop and open PR to RuboCop. It will also reduce dependency from Rails. |
8 tasks
composerinteralia
added a commit
to composerinteralia/rails
that referenced
this pull request
Apr 19, 2018
We added `assert_not` in f75addd "to replace warty 'assert !foo'". fa8d35b agrees that it is warty, and so do I. This custom Rubocop rule turns the wart into a violation. As with my last custom cop, rails#32441, I want to make sure this looks right on code climate before pushing another commit to autocorrect everything. @toshimaru I just noticed toshimaru/rubocop-rails#26 Is there a better way to add these custom cops, or were you saying we shouldn't have custom cops at all?
bogdanvlviv
added a commit
to bogdanvlviv/rails
that referenced
this pull request
Apr 19, 2018
This commit fix pattern of filenames for `CustomCops/AssertNot` and `CustomCops/RefuteNot`. rubocop should check every file under `test/`. Related to rails#32441, rails#32605
koic
added a commit
to koic/rubocop
that referenced
this pull request
Apr 20, 2018
## Summary This PR imports a custom cop from rails/rails#32441. The cop name has changed, but behavior is the same. This cop checks for use of `refute` method series. ```ruby # bad refute false refute_empty [1, 2, 3] refute_equal true, false # good assert_not false assert_not_empty [1, 2, 3] assert_not_equal true, false ``` `assert_not` methods are not minitest's memthods. It is an aliases defined in Active Support (`ActiveSupport::TestCase`). https://github.com/rails/rails/blob/v5.2.0/activesupport/lib/active_support/test_case.rb#L54-L68 So I put this cop in Rails department. I think this cop has a useful opportunity in Rails applications. ## Other Information In the near future this PR aims to replace `CustomCops/RefuteNot` cop of rails/rails repo with this `Rails/RefuseMethods` cop.
bbatsov
pushed a commit
to rubocop/rubocop
that referenced
this pull request
Apr 21, 2018
## Summary This PR imports a custom cop from rails/rails#32441. The cop name has changed, but behavior is the same. This cop checks for use of `refute` method series. ```ruby # bad refute false refute_empty [1, 2, 3] refute_equal true, false # good assert_not false assert_not_empty [1, 2, 3] assert_not_equal true, false ``` `assert_not` methods are not minitest's memthods. It is an aliases defined in Active Support (`ActiveSupport::TestCase`). https://github.com/rails/rails/blob/v5.2.0/activesupport/lib/active_support/test_case.rb#L54-L68 So I put this cop in Rails department. I think this cop has a useful opportunity in Rails applications. ## Other Information In the near future this PR aims to replace `CustomCops/RefuteNot` cop of rails/rails repo with this `Rails/RefuseMethods` cop.
koic
added a commit
to rubocop/rubocop-rails
that referenced
this pull request
Oct 26, 2018
## Summary This PR imports a custom cop from rails/rails#32441. The cop name has changed, but behavior is the same. This cop checks for use of `refute` method series. ```ruby # bad refute false refute_empty [1, 2, 3] refute_equal true, false # good assert_not false assert_not_empty [1, 2, 3] assert_not_equal true, false ``` `assert_not` methods are not minitest's memthods. It is an aliases defined in Active Support (`ActiveSupport::TestCase`). https://github.com/rails/rails/blob/v5.2.0/activesupport/lib/active_support/test_case.rb#L54-L68 So I put this cop in Rails department. I think this cop has a useful opportunity in Rails applications. ## Other Information In the near future this PR aims to replace `CustomCops/RefuteNot` cop of rails/rails repo with this `Rails/RefuseMethods` cop.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since at least cf4afc4 we have preferred
assert_notmethods overrefutemethods in our tests. I have seen plenty of comments in PRs about this, and we have
tried to fix it a few times (5294ad8, e45f176, 8910f12, 41f50be,
d4cfd54, 48a183e, and 211adb4), but the
refutemethods keep sneaking back in.This custom RuboCop will take care of enforcing this preference, so we
don't have to think about it again. I suspect there are other similar
stylistic preferences that could be solved with some custom RuboCops, so
I will definitely keep my eyes open.
assert_notoverassert !mightbe a good candidate, for example.
I wasn't totally sure if
ci/custom_copswas the best place to putthis, but nothing else seemed quite right. At one point I had it set up
as a gem, but I think custom cops like this would have limited value
in another context.
I want to see how code climate handles the new cops beforeautocorrecting the existing violations. If things go as expected, I will
push another commit with those corrections.
Failed the build as expected.
rubocop -afixed all the new violations, so hopefully code climate is happy this time.