This rule was added in rubocop-capybara 2.19.0. We were following it
about 85% of the time.
Now we won't have to check both have_css and have_selector when
searching the code.
Note we're excluding a few files:
* Configuration files that weren't generated by us
* Migration files that weren't generated by us
* The Gemfile, since it includes an important comment that must be on
the same line as the gem declaration
* The Budget::Stats class, since the heading statistics are a mess and
having shorter lines would require a lot of refactoring
We were checking that the price of the investment isn't present on the
page. However, the text "200" could be present in either the title of
the budget or the title of the heading ("Heading 200"), for instance. So
now we're making sure we look for the text on the relevant part of the
page.
We were getting some failures because sometimes the titles which are
generated automatically (like "Budget Investment 200 title") contained
the price of the investment, and so, when testing the presence of the
price (200, in this case), the test was failing.
So we're adding a custom title to the investments we create during the
tests.
We were testing that the `calculate_winners` method does not take the
price into account; we can do the same in a model test. We already have
a different system test to check that the price isn't displayed in the
view.
The test was always passing because incompatible investments are only
shown after clicking on the "Show all" link. So now we're clicking the
link before checking the "incompatibles" table isn't shown.
I don't think "incompatibles" is a valid English word; for now, I'm
leaving it like this until a native English speaker reviews it.
It's strange to create records without assigning them to a variable and
then query the database to fetch the very same records. Assigning them
to a variable makes the tests easier to understand.
Besides, this way we avoid querying the database after the browser has
started.
JavaScript is used by about 98% of web users, so by testing without it
enabled, we're only testing that the application works for a very
reduced number of users.
We proceeded this way in the past because CONSUL started using Rails 4.2
and truncating the database between JavaScript tests with database
cleaner, which made these tests terribly slow.
When we upgraded to Rails 5.1 and introduced system tests, we started
using database transactions in JavaScript tests, making these tests much
faster. So now we can use JavaScript tests everywhere without critically
slowing down our test suite.
