Using order links in this case causes an unusual interface, where we
show filter links, then information about the number of results, and
then order links.
Whether or not this makes sense needs to be confirmed with usability
tests. In any case, this is still way better than using `<select>`
fields which automatically change to a new page, since they cause
problems to keyboard users, are harder to select for touchscreen users,
might confuse screen reader users who will notice a form but no way to
submit it, and are not elements we generally use to let users choose the
order of the records.
For a more detailed explanation of these issues, check the commit
message in the commit "Use order links to sort comments and topics"
(just a few commits ago).
We were checking what happens in the database, but what's important is
what users experience after hiding content or blocking authors. Besides,
accessing the database in tests after the browser has started might lead
to database inconsistencies.
Just like we mentioned in commit 5f0c422eb, the filter "Mark as viewed"
doesn't work properly, so here's a case where the test would fail with
JavaScript not because the test is wrong, but due to a bug. The test was
passing simplify because there was a typo in the CSS selector, which was
supposed to select an element by ID but didn't have the "#" prefix.
For now we're keeping the test as it was, but eventually we'll have to
fix the bug.
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.
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.
