Note that the `budget` parameter was added to the `delete_path` method
so it works in the tests; on production, it worked because this
component is only rendered on pages which already have the `budget`
parameter.
Co-authored-by: Javi Martín <javim@elretirao.net>
This was accidentally introduced in commit 64aa1ffe0. Pronto didn't
detect it because the line itself was fine; the problem lied in its
place within the file.
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.
Many pages had this tag, but many other didn't, which made navigation
inconsistent for people using screen readers.
Note that there are slight changes in two pages:
* The homepage now includes the banner and the content of the
`shared/header` element inside the <main> tag
* The budgets index now includes the banner inside the <main> tag
I see both potential advantages and disadvantages of this approach,
since banners aren't necessarily related to the main content of a page
but on the other hand they aren't the same across pages and people using
screen readers might accidentally skip them if they jump to the <main>
tag.
So I'm choosing the option that is easier to implement.
Note we're adding a `public-content` class to the <main> element in the
application layout. This might be redundat because the element could
already be accessed through the `.public main` selector, but this is
consistent with the `admin-content` class used in the admin section, and
without it the <main> element would sometimes have an empty class
attribute and we'd have to use `if content_for?(:main_class)` or
`tag.main` which IMHO makes the code less consistent.
The Capybara::DSL monkey-patch is only done on the `visit` method
because it's the only reliable one. Other methods like `click_link`
generate AJAX requests, so `expect(page).to have_css "main", count: 1`
might be executed before the AJAX request is finished, meaning it
wouldn't properly test anything.
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.
