Add new `Capybara/RedundantWithinFind` cop

ydah commented 10 months ago

Resolve: https://github.com/rubocop/rubocop-capybara/issues/75

Before submitting the PR make sure the following are checked:

[x] Feature branch is up-to-date with main (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Updated documentation.
[x] Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
[x] The build (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:

[x] Added the new cop to config/default.yml.
[x] The cop is configured as Enabled: pending in config/default.yml.
[x] The cop documents examples of good and bad code.
[x] The tests assert both that bad code is reported and that good code is not reported.
[x] Set VersionAdded: "<<next>>" in default/config.yml.

bquorning commented 9 months ago

Can you please run this against real-world-rspec?

Why don’t we make a GitHub Action that tests the branch against real-world-rspec, e.g. when a certain label is added to the PR?

pirj commented 9 months ago

It breaks quite frequently. Primary branch naming changes, removed repos, renamed repos, etc. With submodules, it’s a pita to keep it up to date. I just have something checked out on my local. Checking out each time as a GHA would do would most certainly break often. Apart from that, rubocop configs should be removed. And —only <cop> sometimes failed, e.g. for rubocop-factory_girl and rubocop-capybara, where new cops don’t make their way to .rubocop.yml, only to config/defaults.yml

ydah commented 8 months ago

I ran it through RSpec on a large Rails app and it seemed to work fine:

❯ bundle exec rubocop --only Capybara/RedundantWithinFind -A
Inspecting 11985 files
(snip)
11985 files inspected, 347 offenses detected, 347 offenses corrected

rubocop / rubocop-capybara

Add new `Capybara/RedundantWithinFind` cop #77