Remove RSpec/Capybara/FeatureMethods

[ydah]

Fix: #1852

---

Before submitting the PR make sure the following are checked:

• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Updated documentation.
• Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
• 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 modified an existing cop's configuration options:

• Set VersionChanged: "<<next>>" in config/default.yml.

[bquorning]

I am curious to hear what @pirj thinks of this PR.

[pirj]

It doesn’t feel right to change the config by default.
We can’t imply that those methods are always for capybara specs.
I can’t quickly find it, but I recall someone mentioned that ‘describe’ isn’t a safe correction for ‘feature’ that has a certain metadata attached to it by default.

I suggest instead adding what needs to be done to this message below:

in .rubocop.yml file, enable `RSpec/Dialect`.

[bquorning]

I agree. One thing we could do it to link from the obsoletion.yml message to https://docs.rubocop.org/rubocop-rspec/cops_rspec.html#rspecdialect, and add to the documentation in

rubocop-rspec/lib/rubocop/cop/rspec/dialect.rb

Lines 42 to 47 in 6f34025

	# # ...
	# end
	#
	class Dialect < Base
	extend AutoCorrector
	include MethodPreference

diff --git a/lib/rubocop/cop/rspec/dialect.rb b/lib/rubocop/cop/rspec/dialect.rb
index 7140541c..95d75161 100644
--- a/lib/rubocop/cop/rspec/dialect.rb
+++ b/lib/rubocop/cop/rspec/dialect.rb
@@ -42,6 +42,19 @@ module RuboCop
       #     # ...
       #   end
       #
+      # If you were previously using the `RSpec/Capybara/FeatureMethods` cop and
+      # want to keep disabling all Capybara-specific methods that have the same
+      # native RSpec method (e.g. are just aliases), use the following config:
+      #
+      #   RSpec/Dialect:
+      #     PreferredMethods:
+      #       background: :before
+      #       scenario:   :it
+      #       xscenario:  :xit
+      #       given:      :let
+      #       given!:     :let!
+      #       feature:    :describe
+      #
       class Dialect < Base
         extend AutoCorrector
         include MethodPreference

[pirj]

Nice! A small note on config, otherwise looks good. Thank you!

I’m sorry if I’ve missed that in some other ticket/pr/discussion, is there anything that’s stopping us from releasing 3.0 with those breaking changes as our next release? I’ve seen that we have two branches now.

[bquorning]

I’m sorry if I’ve missed that in some other ticket/pr/discussion, is there anything that’s stopping us from releasing 3.0 with those breaking changes as our next release? I’ve seen that we have two branches now.

No, I don’t think there’s a whole lot more to be done before releasing a v3.0 ✨ I started a discussion at #1880.

[bquorning]

@ydah Could you please rebase once again?

Related: Should I enable the “Always suggest updating pull request branches” feature for the repo?

Whenever there are new changes available in the base branch, present an “update branch” option in the pull request.

That would mean other maintainers could easily rebase a PR (or merge origin/master in), but perhaps at the cost of (many) more commits, and a more confusing workflow for the contributor whose local branch no longer matches the remote.

[ydah]

@bquorning I did it!

That would mean other maintainers could easily rebase a PR (or merge origin/master in), but perhaps at the cost of (many) more commits, and a more confusing workflow for the contributor whose local branch no longer matches the remote.

I think it's a very good point of view. IMO, but we don't want to rush the merge. And confuse PR authors. So I think it's fine the way it is.

[bquorning]

Perfect ❤️

[pirj]

Incredible! Thank you!

One last smoke check - does rubocop-capybara’s spec suite still pass with this?

[bquorning]

does rubocop-capybara’s spec suite still pass with this?

I tried it locally, and the specs and most of the rubocop check pass.

[bquorning]

I ran rubocop with this branch of rubocop-rspec on a rather large project at work, and the only unexpected issue I encountered was the problem with rubocop-rspec_rails described in #1884 (which is easily fixed after our next release). This PR is ready to merge!