Add new Capybara/RSpec/HaveContent cop

[nzlaura]

Addresses issue:

• Resolves Cop Idea: have_content vs have_text #134

Capybara supports both methods, but as the former is more concise, this cop standardises on using have_text and have_no_text over have_content or have_no_content, which will help with consistency in codebases using them.

It makes it clearer using have_text because the matcher is checking visible text rather than content in a broader sense, and have_content is just an alias for the method. As far as I know there's no functional advantage to using have_content so standardising on one seems sensible?

Capybara also supports assert_text - so I think that's another important reason to support have_text, just having that consistent naming across the RSpec and minitest options is helpful when using them in a codebase.

---

Before submitting the PR make sure the following are checked:

• Feature branch is up-to-date with main (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 created a new cop:

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

If you have modified an existing cop's configuration options:

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

[r7kamura]

I believe it is beneficial to provide a cop that unifies multiple approaches yielding the same result into one. Such cops have been provided by this gem in the past as well. Therefore, I personally think that this kind of cop is acceptable.

The points that I was interested in are as follows:

1. You should explain the clear reason why have_text is always better than have_content in the doc comments. For example, the fact that it's shorter, how good short code is, or that Capybara's official documentation recommends it, or some performance reason, etc. If no special reason can be shown and it's merely a matter of preference, then preferences should be switchable by EnforcedStyle.
2. If a clear reason can be shown as mentioned above, how about Capyabara/HaveContent (or Capybara/RSpec/HaveContent) as the cop name? I believe there are various opinions regarding cop naming conventions, but I personally prefer names that represent bad styles. Therefore, in cases where there is a binary choice, with one option being inherently bad, I prefer a cop like HaveContent. This makes it easier to understand that "have_content" is not good.
3. Some cops in this gem are included in the department Capybara/RSpec, but what criteria are used to decide whether a particular cop should be included in this department? Are all existing cops following some specific criteria, or is there no consistency? Furthermore, should this cop be included there this time?

[r7kamura]

should this cop be included there this time?

@ydah I believe you are knowledgeable about Capybara/RSpec as you have proposed the following pull request regarding it.

• Move the department associated with Capybara::RSpecMatchers to Capybara/RSpec/* #155

There is a possibility that this pr might conflict with your pr. Do you have any opinions about this cop?

[nzlaura]

hi @r7kamura thanks for the feedback 😄

1. I can add add a bit more detail to the doc comments- I do think have_text is beneficial over have_content- not simply because of style. Though because have content is an alias, it might be worth making it switchable as people may have one or the other in their codebase (and prefer to keep it that way rather than switching away from the aliased version to have_text).

It makes it clearer using have_text because the matcher is checking visible text rather than content in a broader sense, and have_content is just an alias for the method. As far as I know there's no functional advantage to using have_content so standardising on one seems sensible?

Capybara also supports assert_text - so I think that's another important reason to support have_text, just having that consistent naming across the RSpec and minitest options is helpful when using them in a codebase.

2. That is a really good point on the naming, I agree and I'll switch up the name.

3. I'm happy to go with whatever direction the maintainers would like in terms of where the cop should live, if they feel it makes more sense in the RSpec subgroup it'd be fine with me.

[r7kamura]

Nice! I'm all for adding this cop with this implementation.
We will eventually ask you to squash the commits into a single commit when merging.

I believe the final decision on whether to use Capybara/RSpec/HaveContent or just Capybara/HaveContent will depend on the outcome of the following PR, so please wait a little longer for that decision:

• Move the department associated with Capybara::RSpecMatchers to Capybara/RSpec/* #155

@rubocop/rubocop-rspec Please let us know if you have any other opinions about this cop.

[ydah]

Agreed! I think Capybara/RSpec/HaveContent is appropriate here. Could you please update it?

[nzlaura]

@ydah sure thing, I'll update it, then squash my commits down to one commit too 😄

[r7kamura]

Suggested change

[nzlaura]

Removed and squashed 😄

[r7kamura]

It's a minor thing, but there's an unnecessary line break, so please remove it and squash it. Other than that, it's perfect! I plan to merge it once that's fixed.

[r7kamura]

Thank you for your contribution!