The `type: :feature` is automatically detected by RSpec because these
tests are inside the `spec/features` folder. Using `feature` re-adds a
`type: :feature` to these files, which will result in a conflict when we
upgrade to Rails 5.1's system tests.
Because of this change, we also need to change `background` to `before`
or else these tests will fail.
When params[:budget_investment][:valuation_tag_list] was not present,
which is the case when updating an investment using the "mark as visible
to valuators" checkbox, we were removing all valuation tags.
Using a virtual attribute to assign the tags only if the parameter is
present simplifies the code in the controller and avoids the issue.
So under the tab "without valuator" we don't show investments assigned
to a valuator group, just as expected by administrators.
There was a conflict while applying this commit to the CONSUL repo. I've
decided to re-introduce the test which was deleted in commit dddf026a,
which hadn't been deleted in AyuntamientoMadrid@192f1182.
After changing the order for budget investments, the selected investment
didn't appear on the first page anymore, and so it couldn't be clicked
on during the test.
As mentioned in the comments in PR #1256:
"These failures take place because the checkbox is already present
before clicking in 'under valuation', and so Capybara doesn't have to
wait for the 'under valuation' request to finish before clicking the
checkbox."
So sometimes Capybara tries to check/uncheck the checkbox at the same
time that checkbox is being replaced by the new content, resulting in no
request being sent to the server.
Making Capybara check the page to ensure the new content is already
loaded before checking/unchecking the checkbox solves the problem.
Changes introduced in commits 41f66fa and dc87b75 will render the
'See results' button under `admin/budget_investments` only if a
finished budget has winner investments associated with it
Also changed the name of the param to `min_total_supports`, which is more descriptive on what it actually does.
Backport of 75f20d5 and 07f0806 from AyuntamientoMadrid/consul fork
Add feature spec to test if the 'Calculate winners'
button is enabled or not, depending on the phase.
It also checks the message that clarifies why the
button is disabled.
There's no need to check again headers in this scenario, previous one
already does it.
Correctly naming variables, as well as using explicit expectations is a
good idea.
Last but not least, expectations where reversed but by luck or lack of
attention where passing.
The created investment didn't had all data to correctly assert each
column values are correctly exported.
The expectations checking if each particular text appears are invalid in
this test. The objective is to check that the downloaded file contents
are exactly as they should be... not particular parts checked in an
independent way as for example "Yes" could appear in two different
columns and just looking if the text appears is not a valid assertion.
