In some places, we were accidentally creating records after the browser
started because we weren't executing a `let` block before starting the
browser with a `visit`, but were executing the `let` block after that.
These blocks are no longer used:
* `allowed_phase_list` isn't used since commit 04605d5d5
* `level_two_user` isn't used since commit 26d14cbd0
* `heading` in `budgets/stats_spec` was added in c2457e36a but never
used
* `translatable` was added in 44d137a4c but it's overwritten in all the
contexts.
* `annotation` isn't used since commit 79d00e7b9
* `admin` in `tags/budget_investments_spec` isn't used since 8a2e15980
* `budget` in `welcome_spec` was added in 87be6f302 but never used
When we create a budget heading through factories it's placed at Puerta del Sol,
Madrid. It seems reasonable that the `map_location` factory places the points near
there.
Before these changes sometimes the map center was placed in Madrid while map
locations were placed in Greenwich, therefore markers were not visible in the
map current pane.
For the HashAlignment rule, we're using the default `key` style (keys
are aligned and values aren't) instead of the `table` style (both keys
and values are aligned) because, even if we used both in the
application, we used the `key` style a lot more. Furthermore, the
`table` style looks strange in places where there are both very long and
very short keys and sometimes we weren't even consistent with the
`table` style, aligning some keys without aligning other keys.
Ideally we could align hashes to "either key or table", so developers
can decide whether keeping the symmetry of the code is worth it in a
case-per-case basis, but Rubocop doesn't allow this option.
We were using `map_location` in one place and
`location-map-remove-marker` in another one. We usually use dashes in
HTML class names, we don't say "location map" anywhere else.
While reviewing commit 7702b551e, I forgot to test whether selecting
text in the budget header or clicking its link worked properly.
The negative index (-5) meant it was impossible to select its text or
click on its link.
The good news is the pseudoelement with a negative index (-1) is
considered a child of the .budget-header element, so having a negative
index will cause the pseudoelement to be render behind the content of
the .budget-header element but in front of the background of the
.budget-header element.
This is exactly what we want.
Originally, we didn't have a z-index in the .budget-header element,
meaning the pseudoelement was rendered behind the background of the
.budget-header element, meaning both backgrounds were visible. This was
OK when the background was a plain color, but it wasn't when the
background was an image.
To stress the fact that the budget header is only affected when we use
an image, I'm also moving the code inside the `.with-background-image`
selector, although it would be interesting to check whether it's a good
idea to add `z-index: 0` to the `full-width-background` mixin.
We forgot to do so in commit 04605d5d5. Before that commit, we were
testing the links weren't displayed in the "informing" phase as opposed
to the "finished" phase. After that commit, they weren't displayed
anywhere since a <select> field was shown instead.
Since then, we've replaced the <select> field with the links generated
by the `Budgets::Investments::FiltersComponent`. We've already got tests
for these links.
We're going to make a change, and it's easier if we've already got a
component with tests so we don't have to write system tests to check
whether the map is rendered.
It was accidentally introduced in commit 756a16f67. Pronto didn't warn
us because in that commit we deleted the code where the `group` method
was used.
The interface was a bit confusing, since after clicking on "See
unfeasible investments" (or similar), we were on a page where no
investments were shown.
Besides, since commit 7e3dd47d5, the group page is only linked from the
"my ballot" page, through a link inviting the user to vote in that
group, and it's only possible to vote selected investments (which is the
default filter during the final voting phase).
The only reason we had these links here was these links weren't present
in the investments page. But they're present there since commit
04605d5d5, so we don't need them in the group page anymore.
These tests don't work without JavaScript. They were passing because the
`within` method always passes in component tests.
This reverts most of commit 822140a14.
In general, slow system tests requiring no interaction from the user are
good candidates to be moved to component tests because component tests
are much faster.
In this case, the system tests were also updating the database after
starting the browser, which might cause concurrency issues. We could
split the test and have one system test per phase, but IMHO there's no
need.
We're still having a couple of system tests for the happy path, in order
to make sure users actually see the list of investments.
Note we don't cast negative votes when users remove their support. That
way we provide compatibility for institutions who have implemented real
negative votes (in case there are / will be any), and we also keep the
database meaningful: it's not that users downvoted something; they
simply removed their upvote.
Co-Authored-By: Javi Martín <javim@elretirao.net>
Co-Authored-By: Julian Nicolas Herrero <microweb10@gmail.com>
Note one of the tests dealing with random results is a bit flaky; since
it's a permutation selecting 7 objects out of 12, it will fail about
once every 4 million times. We think this is acceptable.
Co-Authored-By: Julian Nicolas Herrero <microweb10@gmail.com>
This way we avoid modifying the database in the middle of a system test
(after we've started the browser), which can lead to database
inconsistencies.
In the case of the reclassification specs we're simply removing part of
the test because that part is already tested by other specs.
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.
Content like lowercase letters with `text-transform: uppercase` or
spaces after elements with `display: block` or "You're on page:" are not
seen that way by users with a browser supporting CSS.
So we're testing what most users actually experience.
The method `formatted_heading_price` depends on the current locale. When
we make a request to `visit budgets_path locale: :es`, the request
modifies `I18n.locale` as well.
However, if we use JavaScript tests, the process running the test is
different than the process handling the request, and so the change in
`I18n.locale` does not affect the test.
Checking against the actual value we expect makes the test work with and
without JavaScript.
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.
There was a big difference between the current budget and a specific
budget landing page. This didn't really make too much sense. Also, it
was not possible to know how a draft participatory budget will look
before it was published.
By unifying those two views now they will look quite similar and it
will be possible for administrators to preview any draft budget and to
know how the budget will look like before actually publishing it.
Using the name instead of using the name and the price is IMHO more
consistent with the rest of the application, particularly for screen
reader users. Writing texts clicking those links is also easier.
I think the main reason why we used the price as part of the link was so
the clickable area was bigger. We can accomplish the same result with
CSS.
Now it's easier to change the investments filter. Previously we had to
go back to the budget index page, change the filter there, and then
select one heading.
Now the links to change the current filter in the budget index page
aren't needed anymore.
There were some issues using `.budget.expanded`, like a link having that
class which would force us to a `:not(.button)` selector or similar,
making the CSS more complex.
Previously the draft mode was a phase of the PB, but that had some
limitations.
Now the phase drafting disappears and therefore the PB can have the
status published or not published (in draft mode).
That will give more flexibility in order to navigate through the
different phases and see how it looks for administrators before
publishing the PB and everybody can see.
By default, the PB is always created in draft mode, so it gives you
the flexibility to adjust and modify anything before publishing it.
This rule was added in rubocop-rspec 1.39.0. The `visible: false` option
is equivalent to `visible: :all`, but we generally use it meaning
`visible: :hidden` for positive expectations and `visible: :all` for
negative expectations.
The only exceptations are tests where we count the number of map icons
present. I'm assuming in this case we care about the number of map icons
independently on whether they are currently shown in the map, so I'm
keeping the `visible: :all` behavior in this case.
