The method `tag_list_on` doesn't add an `ORDER_BY` clause to the SQL
query it generates, and so results may come in any order.
However, in the tests we were assuming the tags were ordered by ID in
descending order. Since that isn't always the case, the tests were
failing sometimes.
Ordering the tags alphabetically solves the problem. We could also use
the same order admins used when adding the tags:
```
@process.customs.order("taggings.created_at").pluck(:name).join(", ")
```
However, I'm not sure it improves the user experience, and it makes the
code more complicated.
benefit to administratos.
It looks like sometimes, particularly when the first thing we do after
loading a page is filling the CKEditor fields and submitting the form,
CKEditor doesn't have enough time to format the text, and so it's sent
as plain text instead of HTML. This behaviour can be reproduced on my
local machine after upgrading to Rails 5.1, with the test "Admin Active
polls Add" failing 100% of the time.
Checking CKEditor has been filled in correctly solves the issue.
These changes fix a bug that causes categories
of a legislation process to be wiped on update
of the process. It also adds a regression test
for this fix.
We were very inconsistent regarding these rules.
Personally I prefer no empty lines around blocks, clases, etc... as
recommended by the Ruby style guide [1], and they're the default values
in rubocop, so those are the settings I'm applying.
The exception is the `private` access modifier, since we were leaving
empty lines around it most of the time. That's the default rubocop rule
as well. Personally I don't have a strong preference about this one.
[1] https://rubystyle.guide/#empty-lines-around-bodies
There's a very common pattern in our test, where the setup only has two
lines:
variable = create(:something)
unused_variable = create(:something_else, something: variable)
In this case, since there's a blank line below these ones and then we'll
get to the body of the test, and the second variable is going to be
created based on the first variable, we can remove the useless
assignment and the readability is still OK.
Another option we almost unanimously discarded was:
variable = create(:something)
_unused_variable = create(:something_else, something: variable)
We don't use it anywhere else, either.
One more option we considered but found a bit too much for simple tests:
variable = create(:something) do |something|
create(:something_else, something: variable)
end
Then of course we could move the setup to `let` and `before` blocks, but
the tests could get over-structured really quickly.
These feature tests were taking too long, we can't run them for every
single model.
I'm taking the approach of using one different model for each test, but
in theory only using a few models covering every possible scenario
would be enough.
Settings are stored in the database, and so any changes to the settings
done during the tests are automatically rolled back between one test and
the next one.
There were also a few places where we weren't using an `after` block but
changing the setting at the end of the test.
We understand languages management as the ability to add new languages
or remove existing ones. When no option is passed it will allow language
manipulation by default.
There are 3 special places where we want block languages management:
- admin legislation processes homepage
- admin legislation processes milestones summary
- proposals retired form
Co-Authored-By: Sebastia <sebastia.roig@gmail.com>
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.
The content 'An example legislation process' is already present before
we click the "All" link.
Not checking the page content properly sometimes resulted in the second
click being executed before the first request had been completed, making
the spec fail.
By checking the "All" link isn't present anymore, we guarantee the
request has been completed before trying to click the 'An example
legislation process' link.
This way we can show/hide that div when displaying translations, and we
can remove the duplication applying the same logic to the label, the
input, the error and the CKEditor.
This way we also solve the problem of the textarea of the CKEditor
taking space when we switch locales, as well as CKEditor itself taking
space even when not displayed.
Updating it required reorganizing the form so translatable fields are
together.
We also needed to add a `hint` option to the form label and input
methods so the hint wouldn't show up for every language.
Finally, the markdown editor needed to use the same globalize attributes
as inputs, labels and hints, which adds a bit of duplication.
The test was failing sometimes because of the sequence:
within('#side_menu') do
click_link "Collaborative Legislation"
end
click_link "All"
expect(page).to have_content 'An example legislation process'
click_link 'An example legislation process'
Right after clicking the "Collaborative Legislation" link, the link 'An
example legislation process' is already available. So sometimes Capybara
might click the links "All" and 'An example legislation process' at more
or less the same time, causing the second link not to be correctly
clicked.
Making sure the "All" link doesn't exist anymore we guarantee Capybara
will wait for the previous AJAX request to finish before clicking the
next link.
Note the test to "Create Valid legislation question" is almost identical
but it doesn't fail because it doesn't use Capybara's JavaScript driver.
