Note that the click_link "Reply" is now inside a "within".
This is due to the case of "legislation_annotation" before in the original test
no comment was created as it simply took the one created by default when creating
a "legislation_annotation".
```
annotation = create(:legislation_annotation, author: citizen)
comment = annotation.comments.first
```
Now to try to unify this test, we always create a comment, and in this case as we
also created the "legislation_annotation" we have 2 comments, so it is necessary
to add the "click_link" inside the "within".
Note that the click_link "Reply" is now inside a "within".
This is due to the case of "legislation_annotation" before in the original test
no comment was created as it simply took the one created by default when creating
a "legislation_annotation".
```
annotation = create(:legislation_annotation, author: citizen)
comment = annotation.comments.first
```
Now to try to unify this test, we always create a comment, and in this case as we
also created the "legislation_annotation" we have 2 comments, so it is necessary
to add the "click_link" inside the "within".
Note that the click_link "Reply" is now inside a "within".
This is due to the case of "legislation_annotation" before in the original test
no comment was created as it simply took the one created by default when creating
a "legislation_annotation".
```
comment = annotation.comments.first
```
Now to try to unify this test, we always create a comment, and in this case as we
also created the "legislation_annotation" we have 2 comments, so it is necessary
to add the "click_link" inside the "within".
Note that the click_link "Reply" is now inside a "within".
This is due to the case of "legislation_annotation" before in the original test
no comment was created as it simply took the one created by default when creating
a "legislation_annotation".
```
annotation = create(:legislation_annotation, author: citizen)
comment = annotation.comments.first
```
Now to try to unify this test, we always create a comment, and in this case as we
also created the "legislation_annotation" we have 2 comments, so it is necessary
to add the "click_link" inside the "within".
Note that, in all cases except in :legislation_annotation, the behavior for
click_link is now slightly different.
Previously, the click_link outsite of within block meant that we made sure there
was only one link with that text in the whole page. Now, in order to unify this
spec we change the behaviour.
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
Note we're using the in-favor HTML class instead of the in_favor class
so we're consistent with our conventions for HTML classes and because we
use the in-favor class in similar places.
Also note the styles of the legislation process annotations/comments
buttons is now similar to the styles in the other sections. Previously,
the colors didn't have enough contrast and there was a very strange
margin between the "thumbs up" icon and the number of people agreeing
(that margin wasn't present between the "thumbs down" icon and the
number of people disagreeing).
It was a bit frustrating to click on one of the order elements or the
link to the next page and having to scroll down again until reaching the
comments.
We use order links in many places in the web. However, in the comments
section and the list of community topics, we were displaying a
`<select>` element, and changing the location when users select an
option.
This has several disadvantages.
First, and most important, it's terrible for keyboard users. `<select>`
fields allow using the arrow keys to navigate through their options, and
typing a letter will select the first option starting with that letter.
This will trigger the "change" event and so users will navigate through
a new page while they were probably just checking the available options
[1]. For these reasons, WCAG Success Criterion 3.2.2 [2] states:
> Changing the setting of any user interface component does not
> automatically cause a change of context unless the user has been
> advised of the behavior before using the component.
Second, the form didn't have a submit button. This might confuse screen
reader users, who might not know how that form is supposed to be
submitted.
Finally, dropdowns have usability issues of their own [3], particularly
on mobile phones [4]
The easiest solution is to use the same links we generally use to allow
users select an order, so using them here we make the user experience
more consistent. They offer one disadvantage, though; on small screens
and certain languages, these links might take too much space and not
look that great. This issue affects pretty much every place where we use
order or filter links, so we might revisit it in the future.
Note we're moving the links to order comments after the form to add a
new comment. In my opinion, having an element such as a form to add a
new comment between the element to select the desired order of the
comments and the comments themselves is a bit confusing.
[1] https://webaim.org/techniques/forms/controls#javascript
[2] https://www.w3.org/WAI/WCAG21/Understanding/on-input.html
[3] https://www.youtube.com/watch?v=CUkMCQR4TpY
[4] https://www.lukew.com/ff/entry.asp?1950
GitHub Actions is failing to finish sometimes. Usually that happens due
to concurrency issues when the process running the test accesses the
database after the process running the browser has started.
Since these files were the ones being tested the times we had this
issue, these are the ones we are fixing right now, although there are
probably other places where we might have this issue in the future.
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.
While running our test suite, we were getting an exception sometimes:
```
Proposal Notifications In-app notifications from the proposal's author Followers should receive a notification
Failure/Error: notification_for_user2 = Notification.find_by(user: user2)
ActiveRecord::StatementInvalid:
PG::ProtocolViolation: ERROR: bind message supplies 0 parameters, but prepared statement "" requires 2
: SELECT "notifications".* FROM "notifications" WHERE "notifications"."user_id" = $1 LIMIT $2
# ./spec/system/proposal_notifications_spec.rb:268
```
Sometimes we were getting a similar exception in a different test:
```
Commenting legislation questions Merged comment threads Reply on a multiple annotation thread and display it in the single annotation thread
And sometimes we were getting a different one:
Failure/Error: annotation.comments.roots.sort_by_most_voted.limit(Legislation::Annotation::COMMENTS_PAGE_SIZE).each do |comment|
ActionView::Template::Error:
PG::ProtocolViolation: ERROR: bind message supplies 0 parameters, but prepared statement "" requires 3
```
My best (wild) guess is these exceptions might take place because the
test is accessing the database and at the same time the browser
(chromedriver) process is accessing the database, with code like:
```
find(".icon-notification").click
notification_for_user2 = Notification.find_by(user: user2)
```
Or:
```
first(:css, ".annotator-hl").click
(...)
comment = annotation1.comments.first
click_link "Reply"
```
This behavior happened sometimes while using transactional fixtures and
a shared database connection with feature specs (before system specs
were introduced in Rails 5.1) when some queries were triggered from the
test after the browser process was started.
So we're avoiding the situation by writing the tests from the user's
point of view. This is just an attempt at fixing the issue; I don't know
whether these changes will fix it since I've only seen this exception on
Github Actions (never on my machine). Worst case scenario, we're still
improving the tests legibililty.
We were repeating the same code over and over (with a few variants) to
setup tests which require an administrator. We can use a tag and
simplify the code.
