-
Notifications
You must be signed in to change notification settings - Fork 659
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
Allow configuring the quarantine mode #3891
Comments
Hello @arijo , Thank you for sharing your idea with us. We have decided to add this option in future Testcafe releases. In the meantime, you are welcome to submit your PR. |
This is very important because default retry for -q is 3, which may be high for someone and takes longer to mark test as failed. Ideal retry for test is one more time for majority of the people. Can we prioritize this issue? |
From our testing experiences, running a failed test just one more time doesn't reduce flakiness well. Current settings for quarantine mode feels balanced enough between robustness and time requirements. So we will be happy to accept a PR about this feature, but our team is busy with more important tasks now. |
What I think would be helpful is to have an option to run the failed test again later and not directly after the first initial fail - given that network hiccups usually resolve itself in a few seconds/minutes. Also, if my test succeeds only once in five runs, I'm still happy enough and would like to proceed with the next tests... But I guess that's something not many teams would accept as "stable" |
Hello @dlangerenken , Thank you for sharing your idea with us. We will take it into account. |
From my own experience, the most useful behaviour would be: If a test succeeded in Quarantine Mode at least once, we should mark it as a PASS (even if majority of executions failed). The main thinking behind this: If a test is in Quarantine Mode, it's because it's flaky, so it's not very realistic to expect that it will Pass majority of times. If it passes at least once, that's enough to conclude the functionality is working. Yesterday I was having a quick look at TestCafe code and looks like this is the area that may need to be changed:
|
Hello @Farfurix, Just wondering if this work will be prioritised at some point? Thank you! |
Same question here |
We didn't plan to address this issue in the nearest sprints. In the meantime, you are welcome to submit your PR with this functionality. |
-q n
Hey 👋🏻 . Some of our tests rely on 3rd party tools, which we have no control over (PayPal being the main one). As such, our tests sometimes run as many as 5 times to hit either 3 passes or 3 fails. This tends to cause CircleCi to timeout if the test runs take longer than 10mins to write back to the console. I would find it really beneficial to configure Alternatively, is there a way I can implement something using the TestCafe Runner? |
Hi @rob4629, Since CI terminates a task if there is no output for 10 minutes, you can add some console output at the beginning of your test. You can do this either before each hook or in the custom reporter of the reportTestStart method (https://devexpress.github.io/testcafe/documentation/guides/extend-testcafe/reporter-plugin.html#implement-the-reporter) |
Hey, I spent a little time looking at this, and have a PR. Set testcafe chrome -q
testcafe chrome -q retryCount=2,passCount=1 Update the Threshold values based on this (if provided), otherwise use default (3). Any feedback would be appreciated |
* Implement quarantine [optional] configuration, and unit tests * Update documentation, for quarntine configuration * Add error message, and update unit test to remove typo * Update quarantineMode interfaces to be boolean | Dictionary * Update quarantine to return value as number, not string * WIP: Update test-run-controller, to set the retry/pass threshold values * Update Quarantine Type to be dictionary: number * WIP, update threshold using retryCount and passCount values * Set this._opts.quarantineMode to QuarantineOptionValue interface * Tmp commit, to address PR feedback * Address PR feedback, and set failedThreshold to be retryCount - passCount * Update error message to include passCount value, and set default run threshold to 5 * Move Quarantine class to 'utils/get-options/quarantine.ts' as per feedback * Add functional tests, and update quarantine: _setFailedThreshold based on bug found * try fix tests for task with multiple browsers started once * only local tests Co-authored-by: Alex Kamaev <alexey.kamaev@devexpress.com>
What is your Test Scenario?
Some test are flaky in CI and we would like to increase the number of retries when running in quarantine mode.
What are you suggesting?
A way to configure the number of retries when running the tests in quarantine mode:
-q n
What alternatives have you considered?
Disabling the tests and trying to make the less flaky - but flakiness can depend on other factors like cpu / memory that are not possible to change.
Additional context
Would be nice to know the number of successful tries but not really a priority.
The text was updated successfully, but these errors were encountered: