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.
The valuation comment doesn't show up in the comment show action because
it's not a child of the parent comment. With a regular comment, the test
passes as well.
However, if we make the valuation comment a child of the parent comment,
it shows up both in the index and show actions. That's because the
method `root_descendants` in the `CommentTree` class doesn't filter
valuation comments. I'm not sure whether it's a bug or the intended
behaviour.
Now factories define default headings for investments, so there's no
need to create a group and a heading to create an investment.
Likewise, in order to create a heading it isn't necessary to specify a
group anymore; specifying the budget is enough.
It's possible that there are more similar cases we haven't simplified
yet; I'm only addressing the obvious ones.
These settings are enabled by default.
It could be argued explicitely enabling the features makes tests more
consistent, because they'll work if we change the default setting. It
could also be argued that it makes tests more expressive because it
makes the reader realize certain things will only work if a setting is
enabled.
However, we were only doing so in a few tests. The truth is, thousands
of our tests depend on certain features being enabled. So IMHO we should
be consistent and either set them on every test, or not at all. I'm
choosing the latter option for simplicity.
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've got a bug which causes the admin description not to appear
immediately after commenting, due to the `admin_layout` variable being
false when we add a comment using an AJAX request.
So the test reloaded the page to check the admin description was there.
However, sometimes reloading the page is faster than the AJAX request,
and so the comment is not there yet.
By checking the results of the AJAX request before reloading the page,
the test passes.
A proper solution would be to display the admin description or name
right after the comment is added.
Using arrays made it difficult to order by more than one field (like the
`most_voted` scope does), and so we were ordering by `confidence_score`
and ignoring the `created_at` column.
Using an AR relation makes it easy to reuse the existing `most_voted`
scope.
This change has one side effect: now comments with equal votes are
ordered in descending order instead of having no specific order. That
means flaky specs which failed sometimes because they assumed comments
were ordered by date are now always green.
I've also re-added the `oldest` scope removed in 792b15b thinking it was
removed because using it with arrays was too hard.
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.
As pointed out in PR consul#2734:
"After clicking the first link, there's an AJAX request which replaces
the existing `.in-favor a` and `.against a` links with new elements. So
if Capybara tries to click the existing `.against a` link at the same
moment it's being replaced, clicking the link won't generate a new
request".
Making Capybara check the page for new content before clicking the
second link solves the problem.
This commit solves issues afecting both Madrid's fork and the original
CONSUL repo.
The now-deprecated `.trigger('click')` API simulated a click against
the DOM rather a click on the UI, which made our tests fragile and
wouldn't simulate actual user interaction
Budget Investment factory creates a secondary budget as a collateral
effect because it has a Heading factory that has a Group factory that
creates a Budget.
This was resulting in problems due to having two "active" Budgets created
and `current_budget` method not choosing the one that we expected
How:
Using a local variable at partials to set a hidden true/false value for
`valuation` parameter on the comment creation form.
Allowing that new param at the comment controller and using it when
building a new Comment.
