All these types of tests have already been grouped together in the
comments_specs file which contains different factories including
budget_investments.
I don't think it is necessary to maintain these tests.
The test "display administrator id on public views" is not correct. The valuation comments
are not display never on public views. If we reload this admin page we can see that the
description is render instead of administrator_id as we can see at the upper test:
```
scenario "display administrator description on admin views"
```
The deleted test was passed because there is an error at the moment to render the comments.
As we can see in the file ´app/views/comments/create.js.erb:10´ we try render comment
without valuation value:
```
App.Comments.add_comment(parent_id, "<li><%= j(render @comment) %></li>");
```
That it is necessary to render correctly the description or the id.
By other hand the test "public users not see admin description" is already being checked
in the 'system/comments_specs'. However, we are going to add a new expectation to
make sure that the admin description does not appear on the public pages.
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.
While people using screen readers already have keyboard shortcuts to
jump to the <main> tag, there are people who navigate the page with the
keyboard using just the tab key, and for them, this link provides a way
to save time and start reading the main content instead of having to
manually go through all the navigation links every time a new page is
loaded.
Note that we had to add an additional `width: 0` rule because
Foundation's `element-invisible` would apply `1px` and the test checking
for `visible: :hidden` would faile.
We were testing what happens when clicking on a geozone without HTML
coordinates, which won't happen in a real browser.
So we're now defining the HTML coordinates and clicking on the area in
the test, which is what real people will do.
We also avoid having two consecutive `visit` calls, which will interfere
with the way we plan to test the presence of the <main> tag after every
`visit`.
Note that, the test didn't work with the HTML coordinates defined in the
`with_html_coordinates` trait, with Capybara showing the following
error:
```
Selenium::WebDriver::Error::ElementClickInterceptedError:
element click intercepted: Element
<area shape="poly"
coords="30,139,45,153,77,148,107,165"
href="/proposals?search=California"
title="California" alt="California">
is not clickable at point (413, 456).
Other element would receive the click:
<img usemap="#map" src="/assets/map.jpg">
```
The cause of this error was the strange shape of the polygon, which was
greatly concave and and so the middle of its area wasn't part of it.
We're changing the polygon so it's now convex and when Capybara clicks
on its middle point everything will work as expected.
Note that we keep :created_at order as complement to new :order field.
We do this so that current installations will not notice any change in the
sorting of their cards when upgrading, as the default "order" field will always
be 1, so it will continue to sort by the "created_at".
