Using `have_current_path`, Capybara waits until the condition is true,
while using `include` the expectation is evaluated immediately and so
tests might fail when using a driver supporting JavaScript.
Besides, using `have_current_path` the error message is more readable
when the test fails.
When using tests with a driver supporting JavaScript, there might be
concurrency issues if both the process running the test and the process
running the browser access the database once the browser has been
started.
On JavaScript tests, Rails URL methods don't include the port when
invoked from a test, but they do when invoked from the browser. This was
causing some tests to fail with Selenium.
Checking the `style` attribute fails in JavaScript tests because the
browser converts colors to the `rgb()` format.
So we're testing the generated HTML in a component test while
simplifying the system test.
It isn't very intuitive that this link points to the stats page, but
since it's the only page linking to it and there's no link pointing to
it in the admin navigation, I guess it's better than offering no clue at
all of the current whereabouts.
Somehow I thought it worked automatically, but we had to provide the
token.
The configuration is based on Coveralls instructions to run parallel
builds [1].
Alternatively we could use the Coveralls GitHub Action [2] which
slightly simplifies the workflow configuration and removes the
dependency of the coveralls gem. However, it also adds a dependency on
simplecov-lcov and requires configuring it to renerate LCOV files on
each run, so the benefits of using it are not that big.
[1] https://docs.coveralls.io/parallel-build-webhook
[2] https://github.com/coverallsapp/github-action/
System tests are used to test the application from the user's point of
view. To test for specific exceptions, particularly regarding
authorization permissions, controller tests fit better.
Another option would be to test the page displayed shows a certain text,
like "Internal server error". I'm choosing controller tests because
they're faster and we're basically testing the same scenario many times
and we've already got a test checking what happens when users access a
page raising an exception.
So it's similar to the other custom page 404 tests.
Note we're explicitely marking the page as a draft so it's more obvious
what's going on in the test.
We were testing what happens when users disable features in the admin
panel, so it makes sense to test what happens from the user's point of
view when trying to access a disabled feature: they see a page with the
test "Internal server error".
Whether we should responde with 500 Internal server error page or a 404
Not Found is up to debate; personally I find the latter more
appropriate.
Code based on the article "Changing Rails consider_all_requests_local in
RSpec fails" [1].
[1] http://atodorov.org/blog/2016/04/27/changing-rails-consider_all_requests_local-in-rspec-fails/
Tests are easier to read now. Besides, since we changed the inputs in
the admin section so they don't use jQuery but an HTML date field,
formatting with %d/%m/%Y might not work depending on the browser's
locale.
Some tests were failing depending on the window resolution due to the
datepicker making it impossible to click the "Filter" button. They were
also failing if using `clear: :backspace` to fill in those fields.
So we're focusing on a different field in order to hide the datepicker
and click the "Filter" button.
The line `fill_in "advanced_search_date_max", with: "wrong date"`
doesn't work because the jQuery UI datepicker prevents users from
entering that value.
Using `<a>` tags with no `href` means these elements cannot be activated
by keyboard users, so we're replacing them with buttons.
In the future we probably want to add more consistency so all toggle
buttons use the same code. We might also add styles depending on the
`aria-expanded` property.
The objective of this change is to reduce the size of the images to improve the
experience in slow connections, poor coverage situations or data limits so common in
mobile devices.
Note we're absolutely positioning the link instead of the icon; that way
keyboard users will be able to focus on the icon. Until now, users would
focus on an empty link.
For the same reason, we couldn't use `click_link` with Capybara, since
it would fail to click an empty link. Now we can.
Co-authored-by: Javi Martín <javim@elretirao.net>
