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
Having exceptions is better than having silent bugs.
There are a few methods I've kept the same way they were.
The `RelatedContentScore#score_with_opposite` method is a bit peculiar:
it creates scores for both itself and the opposite related content,
which means the opposite related content will try to create the same
scores as well.
We've already got a test to check `Budget::Ballot#add_investment` when
creating a line fails ("Edge case voting a non-elegible investment").
Finally, the method `User#send_oauth_confirmation_instructions` doesn't
update the record when the email address isn't already present, leading
to the test "Try to register with the email of an already existing user,
when an unconfirmed email was provided by oauth" fo fail if we raise an
exception for an invalid user. That's because updating a user's email
doesn't update the database automatically, but instead a confirmation
email is sent.
There are also a few false positives for classes which don't have bang
methods (like the GraphQL classes) or destroying attachments.
For these reasons, I'm adding the rule with a "Refactor" severity,
meaning it's a rule we can break if necessary.
It's possible to have a given order greater than the number of answers;
we don't have any validation rules for that. So the check for the number
of answers isn't enough.
Checking the maximum given order in the answers is safer. Another option
would be to reorder the answers every time we add a new one, but I'm not
sure whether that's the expected behaviour.
Note even after this change the action is not thread-safe, as it is
possible to create two questions with the same given order with two
simultaneous requests.
The test was hard to follow, and splitting the test in three it's easier
to read and doesn't create unused variables anymore. On the minus side,
now there's one extra request during the tests.
While it could be argued we're hiding the real way we've defined
associations in our models, the tests are so much easier to read when we
don't have so many lines just creating data.
Furthermore, developers who care about vertically aligning the code will
be glad to see some variables disrupting this alignment are now gone.
We barely use this trait. In the votation type spec we're probably using
it wrong, and in the answer spec we assume one of the answers is going
to be "Yes".
The name `yes_no` is more expressive, since it makes it clear what the
answers are.
One test was testing regular users can't access results, and another one
was testing neither regular users nor managers can. So the second test
can just test the admin scenario, and we're still covering everything.
We were performing an AJAX request and then a "normal" request without
checking the AJAX request had finished. Sometimes it resulted in the
normal request finishing because the AJAX request did, causing the test
to fail.
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.
We're also adding a rubocop rule so we dont' accidentally add these
keywords again.
In Rails 5.1, calling `travel_to` inside another `travel_to` block will
result in a RuntimeError:
> Calling `travel_to` with a block, when we have previously already made
> a call to `travel_to`, can lead to confusing time stubbing.
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.
We are trying to avoid Officers from forgetting to click the “Confirm
vote” button, which is necessary to keep track of who has voted a Poll
To do that, we are not displaying the menu item to go back to the next
person that wants to vote, until the Officer clicks the “Confirm Vote”
button or the “The user has decided not to vote” button
Note: Due to mobile version we have duplicate ids, so using classes for
the menu items to hide them without errors
Note2: We are only hidding the menu item, if there are votable polls,
otherwise the “Confirm vote” button does not appear, and there is no
way of going back to help the next person that wants to vote
We needed to bring back support for CKEditor in our translatable form,
which we had temporarily remove.
And now we support CKEditor in our translatable specs, and so we can
remove the duplicated specs for poll question answers.
