Failures:
1) Commenting legislation questions Concerns behaves like notifiable in-app Multiple users commented on my notifiable
Failure/Error: expect(page).to have_content "There are 3 new comments on"
expected to find text "There are 3 new comments on" in "Decide Madrid Language: Transparency Open data Local Forums Blog Notifications My activity My account Sign out Debates Proposals Voting Processes Participatory budgeting Help Notifications Mark all as read Unread Read There are 2 new comments on Question text 2018-03-19 13:54:02 Mark as read Open government This portal uses the CONSUL application which is open-source software. From Madrid out into the world. For technical assistance enters technical assistance Participation Decide how to shape the Madrid you want to live in. Transparency Find out anything about the Madrid City Council. Open data Every detail about the City Council is yours to access. Ayuntamiento de Madrid, 2018 | Privacy Policy | Terms and conditions of use | Accessibility Twitter Facebook Blog YouTube Instagram"
Shared Example Group: "notifiable in-app" called from ./spec/features/comments/legislation_questions_spec.rb:11
# ./spec/shared/features/notifiable_in_app.rb:45:in `block (2 levels) in <top (required)>'
How
[ ] Explain why the test is flaky, or under which conditions/scenario it fails randomly
[ ] Explain why your PR fixes it
Tips for flaky hunting
Random values issues
If the problem comes from randomly generated values, running multiple times a single spec could help you reproduce the failure by running at your command line:
for run in {1..10}
do
bin/rspec ./spec/features/budgets/investments_spec.rb:256
done
You can also try running a single spec in Travis:
Add option :focus to the spec and push your branch to Github, for example:
scenario 'Show', :focus do
But remember to remove that :focus changes afterwards when submitting your PR changes!
Test order issues
Running specs in the order they failed may discover that the problem is that a previous test sets an state in the test environment that makes our flaky fail/pass. Tests should be independent from the rest.
After executing rspec you can see the seed used, add it as an option to rspec, for example:
bin/rspec --seed 55638 (check Randomized seed value at beginning of issue)
Other things to watch for
Time related issues (current time, two time or date comparisons with miliseconds/time when its not needed)
The true objective of this issue is not "to fix" a flaky spec, but to change a spec that randomly fails into one that we can trust when it passes (or fails).
That means you've to think "What are we testing here?" and "Can we test the same thing in another way?" or "Are we already testing this somewhere else at least partially?".
Sometimes the fix is to re-write the entire tests with a different approach, or to extend an existing spec. Tests are sometimes written without taking a look at other tests files neither near scenarios.
Closing this one since we haven't seen this failure for months and since then we've done many changes regarding flaky specs. Some of them might have solved this issue.
What
Tests that fail randomly are called "flakies", this one seems to be one:
Randomized seed: 21955
Travis failed build: Build 9438, job 4
Failure:
How
Tips for flaky hunting
Random values issues
If the problem comes from randomly generated values, running multiple times a single spec could help you reproduce the failure by running at your command line:
You can also try running a single spec in Travis: Add option
:focus
to the spec and push your branch to Github, for example:But remember to remove that
:focus
changes afterwards when submitting your PR changes!Test order issues
Running specs in the order they failed may discover that the problem is that a previous test sets an state in the test environment that makes our flaky fail/pass. Tests should be independent from the rest.
After executing rspec you can see the seed used, add it as an option to rspec, for example:
bin/rspec --seed 55638
(check Randomized seed value at beginning of issue)Other things to watch for
Final thoughts
The true objective of this issue is not "to fix" a flaky spec, but to change a spec that randomly fails into one that we can trust when it passes (or fails).
That means you've to think "What are we testing here?" and "Can we test the same thing in another way?" or "Are we already testing this somewhere else at least partially?".
Sometimes the fix is to re-write the entire tests with a different approach, or to extend an existing spec. Tests are sometimes written without taking a look at other tests files neither near scenarios.