rubocop/rubocop-capybara

Code style checking for Capybara files.

---

Role models are important.
-- Officer Alex J. Murphy / RoboCop

RuboCop is a Ruby static code analyzer (a.k.a. linter) and code formatter. Out of the box it will enforce many of the guidelines outlined in the community Ruby Style Guide. Apart from reporting the problems discovered in your code, RuboCop can also automatically fix many of them for you.

RuboCop is extremely flexible and most aspects of its behavior can be tweaked via various configuration options.

---

Working on RuboCop is often fun, but it also requires a great deal of time and energy.

Please consider financially supporting its ongoing development.

Installation

RuboCop's installation is pretty standard:

$ gem install rubocop

If you'd rather install RuboCop using bundler, add a line for it in your Gemfile (but set the require option to false, as it is a standalone tool):

gem 'rubocop', require: false

RuboCop is stable between minor versions, both in terms of API and cop configuration. We aim to ease the maintenance of RuboCop extensions and the upgrades between RuboCop releases. All big changes are reserved for major releases. To prevent an unwanted RuboCop update you might want to use a conservative version lock in your Gemfile:

gem 'rubocop', '~> 1.63', require: false

See our versioning policy for further details.

Quickstart

Just type rubocop in a Ruby project's folder and watch the magic happen.

$ cd my/cool/ruby/project
$ rubocop

You can also use this magic in your favorite editor with RuboCop's built-in LSP server.

Documentation

You can read a lot more about RuboCop in its official docs.

Compatibility

RuboCop officially supports the following runtime Ruby implementations:

• MRI 2.7+
• JRuby 9.4+

Targets Ruby 2.0+ code analysis.

See the compatibility documentation for further details.

Readme Badge

If you use RuboCop in your project, you can include one of these badges in your readme to let people know that your code is written following the community Ruby Style Guide.

Here are the Markdown snippets for the two badges:

[![Ruby Style Guide](https://img.shields.io/badge/code_style-rubocop-brightgreen.svg)](https://github.com/rubocop/rubocop)

[![Ruby Style Guide](https://img.shields.io/badge/code_style-community-brightgreen.svg)](https://rubystyle.guide)

Team

Here's a list of RuboCop's core developers:

• Bozhidar Batsov (author & head maintainer)
• Jonas Arvidsson
• Yuji Nakayama (retired)
• Evgeni Dzhelyov (retired)
• Ted Johansson
• Masataka Kuwabara
• Koichi Ito
• Maxim Krizhanovski
• Benjamin Quorning
• Marc-André Lafortune
• Daniel Vandersluis

See the team page for more details.

Logo

RuboCop's logo was created by Dimiter Petrov. You can find the logo in various formats here.

The logo is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.

Contributors

Here's a list of all the people who have contributed to the development of RuboCop.

I'm extremely grateful to each and every one of them!

If you'd like to contribute to RuboCop, please take the time to go through our short contribution guidelines.

Converting more of the Ruby Style Guide into RuboCop cops is our top priority right now. Writing a new cop is a great way to dive into RuboCop!

Of course, bug reports and suggestions for improvements are always welcome. GitHub pull requests are even better! :-)

Funding

While RuboCop is free software and will always be, the project would benefit immensely from some funding. Raising a monthly budget of a couple of thousand dollars would make it possible to pay people to work on certain complex features, fund other development related stuff (e.g. hardware, conference trips) and so on. Raising a monthly budget of over $5000 would open the possibility of someone working full-time on the project which would speed up the pace of development significantly.

We welcome both individual and corporate sponsors! We also offer a wide array of funding channels to account for your preferences (although currently Open Collective is our preferred funding platform).

If you're working in a company that's making significant use of RuboCop we'd appreciate it if you suggest to your company to become a RuboCop sponsor.

You can support the development of RuboCop via GitHub Sponsors, Patreon, PayPal, Open Collective and Tidelift .

Note: If doing a sponsorship in the form of donation is problematic for your company from an accounting standpoint, we'd recommend the use of Tidelift, where you can get a support-like subscription instead.

Open Collective Backers

Support us with a monthly donation and help us continue our activities. [Become a backer]

Open Collective Sponsors

Become a sponsor and get your logo on our README on GitHub with a link to your site. [Become a sponsor]

Changelog

RuboCop's changelog is available here.

Copyright

Copyright (c) 2012-2024 Bozhidar Batsov. See LICENSE.txt for further details.

rubocop-capybara's Issues

Cop idea: Detects chained Capybara::Node::Finders#find

# bad
page.find('#foo').find('.bar')

# good
page.find('#foo .bar')

Cop idea: like a `Capybara/FindElementValueEq` cop

original issue: rubocop/rubocop-rspec#1342 (comment)

# bad
expect(find('input').value).to eq('foobar')
# good
expect(page).to have_field(with: 'foobar')

Enhancement: More method support for `Capybara/SpecificFinders`

Currently only find_by_id is supported, but find_link and find_field are supported.

# refs: https://github.com/teamcapybara/capybara?tab=readme-ov-file#name

page.html # => '<a href="/">Home</a>'

page.find(:link) == page.find_link

page.html # => '<input>'

page.find(:field) == page.find_field

Capybara/NegationMatcher is not safe for autocorrect.

I have a file called spec/models/page_spec.rb It does not use capybara.

It has this line:

expect(page).not_to have_content

and rubocop-capybara autocorrects this to:

expect(page).to have_no_content

This now causes my test to fail because the page object (which has nothing to do with Capybara) does not respond to a method called has_no_content?

Autocorrect for expect(current_path) moves method argument when parens are absent

Code like expect(page.current_path).to eq(article_path article) gets autocorrected to

expect(page).to have_current_path(article_path article, ignore_query: true)
The correct form is
expect(page).to have_current_path article_path(article, ignore_query: true)

Cop idea: `first(...)` instead of `all(...)[0]`

https://www.rubydoc.info/gems/capybara/Capybara%2FNode%2FFinders:first

# bad
all('td')[0]

# good
first('td')

Improve "Reference" (and/or rationale in docs) for existing (and future) cops

Background:
The quality of discussion on the PRs in this repo is really top notch and I've learned a lot from reading, e.g. #63 and #61. I initially started looking for the PRs because I couldn't work out what the point of Capybara/RSpec/HaveSelector was. The discussion on #63 was really great. I agree with the comment in that PR that the cops could do with a rationale - either stated within the docs of the cop, or as a Reference. Rubocop's cops mostly have references to the ruby style guide, which is where they draw their rationale.

I notice that the ["Reference")(https://github.com/rubocop/rubocop-capybara/blob/main/config/default.yml#L21) in rubocop-capybara is mostly a reference to itself. I propose that the References should be replaced with the best justification page for them (which in many cases will be the PR which introduced them).

FYI I believe (based on https://github.com/rubocop/rubocop/blob/2fe4b1a6faca23adff13e1bbff6ecf5b66c6447b/lib/rubocop/cop/message_annotator.rb#L102) there can be multiple Urls in the Reference

I think this would massively add to the value of rubocop-capybara. I will make a PR with a couple of starting points and see what people think.

2.19 doc issue - no RSpec department under "Cops Documentation"

https://docs.rubocop.org/rubocop-capybara/cops_capybara.html

Capybara/RSpec cops are not visible in this section, and not in the left sidebar.

But they are visible here https://docs.rubocop.org/rubocop-capybara/cops_capybara_rspec.html

Linked from https://docs.rubocop.org/rubocop-capybara/cops.html

I don't think we have such an issue with e.g. rubocop-rspec, all sub-departments appear under "Cops Documentation":

Cop idea: disallow successive `have_no_css`

This code:

expect(page).to have_no_css('.some-class')
expect(page).to have_no_css('.other-class')

Could be written as:

expect(page).to have_no_css('.some-class, .other-class')

Remove `Capybara/ClickLinkOrButtonStyle` cop

#61 (comment)

Cop idea: Prefer to validate with a `have_*` matcher over retrieve the element with `find_*` and validate

# bad
expect(page.find_link('foo')[:class]).to eq 'some-cls'

# good
expect(page).to have_link('foo', class: 'some-cls')

Capybara/CurrentPathExpectation is not valid when the page has query parameters

The current_path is only the path (no parameters)

expect(current_path).to eq '/reserves/new'

The have_current_path does a comparison on the path + query parameters.

     Failure/Error: expect(page).to have_current_path '/reserves/new'
       expected "/reserves/new?comp_key=AA-272C%2C123%2C456" to equal "/reserves/new"

Cop idea: disallow calling `have_no_XXX` immediately after `visit` (Capybara)

Note the following code:

visit 'google.com'
expect(page).to have_no_link

Will pass... sometimes. It's a race-condition as the page may or may not have loaded when execution reaches the second line. It would be nice to have a cop that checks for these cases.

Not sure if it should also handle:

visit 'google.com'
within 'div'
  expect(page).to have_no_link
end

In some sense the page has already (at least partially) loaded because of the within check but on the other hand perhaps always having a positive check before the negative for sanity is better?

Capybara/NegationMatcher: False negative with to_not

I get an offense when using not_to:

spec/system/some_spec.rb:229:24: C: [Correctable] Capybara/NegationMatcher: Use expect(...).to have_no_css.
          expect(page).not_to have_css(".some-class")
                       ^^^^^^^^^^^^^^^

But not when the same code uses to_not. I guess the code assumes the default config for the NotToNot cop, but that isn't the case everywhere. 🤓

Cop idea: Redundant `within find('foo')`

within find('foo.bar') and within 'foo.bar' have the same behavior.
https://www.rubydoc.info/gems/capybara/Capybara%2FSession:within

We consider it redundant to pass the result of find as the argument of within, since we are executing find internally.
https://github.com/teamcapybara/capybara/blob/0b43cb90ae633ce9b2008e07b997c76833fa570e/lib/capybara/session.rb#L362-L363

# bad
within find('foo.bar') do
end

# good
within 'foo.bar' do
end

official manual is not found

The official manual that documented in README shows "Page Not Found".

rubocop-capybara/README.md

Line 64 in ff1f546

You can read more about RuboCop Capybara in its [official manual](https://docs.rubocop.org/rubocop-capybara).

https://docs.rubocop.org/rubocop-capybara

`RSpec/Capybara/SpecificFinders` autocorrection shoud remove escape

Reproducion steps

Run RSpec/Capybara/SpecificFinders autocorrection on:

find('#domain-deadbeef\.org-delete')

This returns a tag <tag id="domain-deadbeef.org-delete">, which id contains ..
The . shoud be escaped because bare . is a class selector in CSS.

Expected result

find_by_id('domain-deadbeef.org-delete')

CSS selector escape should be removed.

Actual result

find_by_id('domain-deadbeef\.org-delete')

References

Per HTML Standard, id attribute can contain any character except whitespace.
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/id

Cop idea: disallow using `exact_text` when `Capybara.exact = true`

Capybara.exact = true
expect(page).to have_link(exact_text: 'foobar')

It would be nice to have a check that disallows passing exact_text to such matchers as that's unneeded - Capybara.exact makes these matcher work like so by default. That is, the above is equivalent to expect(page).to have_link('foobar').

A couple of things to note:

1. this is perhaps difficult to implement as Capybara.exact = true is generally set in a different file spec_helper.rb. Perhaps an option to the plugin could be passed, not sure?
2. there are exceptions to this. If the text contains new lines, exact_text must be passed (because of teamcapybara/capybara#2533).

Cop idea: Debug method detection

There are some debugging methods in capybara, but it would be nice to have a way to detect the use of these methods.

# bad
save_and_open_page

# bad
page.save_screenshot('screenshot.png')

# bad
save_and_open_screenshot

be similar to: https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Lint/Debugger

Misunderstanding with Capybara/NegationMatcher

Actual behavior

The default behavior of the rubocop-capybara is inconsistent with the rspec style guide.

Reference 1: https://rspec.rubystyle.guide/#capybara-negative-selectors
Reference 2: https://docs.rubocop.org/rubocop-capybara/cops_capybara.html#capybaranegationmatcher

Expected behavior

The rspec style guide will be corrected.

Deprecation warning with JRuby

Running version 2.20.0 on JRuby leads to a bunch of deprecation warnings:

/home/boris/project/build/.gems-rubocop/gems/rubocop-capybara-2.20.0/lib/rubocop/cop/capybara/mixin/css_attributes_parser.rb:19: warning: passing a block to String#chars is deprecated

Is that normal/expected or is it some bug in JRuby?

`Capybara/SpecificFinders` conflicts with `Rails/DynamicFindBy`

Capybara/SpecificFinders suggests the following change:

# bad
find('#some-id')
find('[visible][id=some-id]')

# good
find_by_id('some-id')
find_by_id('some-id', visible: true)

However, find_by_id is going to be flagged by Rails/DynamicFindBy.

These two cops can't be enabled together. If I had to choose from the two, Rails/DynamicFindBy would be my choice and Capybara/SpecificFinders would be disabled.

---

Expected behavior

Capybara/SpecificFinders could somehow respect Rails/DynamicFindBy.

Actual behavior

They have conflicting opinions on code like these.

RuboCop version

➜  rubocop -V
1.43.0 (using Parser 3.2.0.0, rubocop-ast 1.24.1, running on ruby 3.1.3) [arm64-darwin22]
  - rubocop-performance 1.15.2
  - rubocop-rails 2.14.2
  - rubocop-rspec 2.18.0

[Capybara/SpecificMatcher] False-positive when using regex

expect(page).to have_css('button', exact_text: /my regex+/)

This should not trigger the Capybara/SpecificMatcher because there is no way to write this with have_button. Same applies for text with regex in addition to exact_text.

Some `SpecificMatcher` offenses are not being detected

Hello,

apologies if this is a duplicate. I've searched but I couldn't find anything relevant

In the efforts of adding RuboCop Capybara to activeadmin at activeadmin/activeadmin#8025

we've noticed that some offenses are not being detected

Quoting from: activeadmin/activeadmin#8025 (comment)

Maybe RuboCop Capybara does not flag some offenses:

# Offenses: Capybara/RSpec/HaveSelector, Capybara/SpecificMatcher
have_selector("input[name='title']")

# No offenses detected - Interpolation
have_selector("input[name='#{title}']")

# Offense: Capybara/SpecificMatcher
have_css("input[type=submit]")

# No offenses detected (`value` attribute, should be replaceable with `with`)
have_css("input[type=submit][value='x']")

# Offense: Capybara/SpecificMatcher
have_css("input[name='post_author_attributes__first_name_']")

# No offenses: name with multiple `[]`
have_css("input[name='post[author_attributes][first_name]']")

Don't know if these offenses can be detected, but I thought I should report the above

`click_on` vs `click_link` and `click_button`

Reference: https://github.com/teamcapybara/capybara/blob/master/lib/capybara/node/actions.rb

There is no information which style is preferred.

click_link 'New Project'
click_button 'Save'

click_on 'New Project'
click_on 'Save'

Proposal for `Capybara/RSpec` department

The Capybara/SpecificMatcher, Capybara/NegationMatcher, and Capybara/VisibilityMatcher cops depend on methods from the Capybara::RSpecMatchers class.

https://www.rubydoc.info/gems/capybara/Capybara/RSpecMatchers

While these cops were previously implemented in the RuboCop RSpec gem and did not cause any issues, they may not be appropriate for RuboCop Capybara, which is not limited to RSpec extensions.
Therefore, it might be a good to create a separate Capybara/RSpec department to handle these RSpec-specific extensions.