Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix flaky specs: proposals, legislation and probe options Voting comments Update #1606

Conversation

javierm
Copy link

@javierm javierm commented Aug 8, 2018

References

Objectives

Fix the flaky specs that appeared in spec/features/comments/proposals_spec.rb:463 ("Commenting proposals Voting comments Update"), spec/features/comments/legislation_questions_spec.rb:498 and ("Commenting legislation questions Voting comments Update") and spec/features/custom/probe_option_comments_spec.rb:466 ("Commenting Probe Options Voting comments Update").

Explain why the test is flaky, or under which conditions/scenario it fails randomly

As mentioned in consul#2734:

Here's the relevant part of the spec:

visit debate_path(create(:debate))

find('.in-favor a').click
find('.against a').click

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.

Explain why your PR fixes it

Making Capybara check the page for new content before clicking the second link solves the problem.

Does this PR need a Backport to CONSUL?

Yes, but only backport the first commit, since the second one changes code not present in the main CONSUL repo.

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.
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 affecting Madrid's fork but not the original
CONSUL repo.
@javierm javierm force-pushed the 2734_consul_related-fix_flaky_comments_spec branch from beea5f5 to 8b8a191 Compare October 23, 2018 14:37
@javierm javierm merged commit 23018a3 into AyuntamientoMadrid:master Oct 26, 2018
@javierm javierm deleted the 2734_consul_related-fix_flaky_comments_spec branch October 26, 2018 11:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants