-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
[Feature]: Option for jest.retryTimes to retry just after the test fails #14696
Comments
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
Not stale |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
Not stale |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
Not stale |
not stale 🍞 |
I like the idea! |
not stale 🍪 |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
🚀 Feature Proposal
jest.retryTimes() is a great way to deal with flaky tests. It will schedule failed tests to be run AFTER testsuite ends.
Proposition here is to add option, to retry failed test, immidiately after test will fail, without waiting for test suite to finish first.
Motivation
I need to design tests in a different way, when I use and don't use
retry
Consider such test suite:
Test design is proper here. I can run all tests together, I can run them separate. But if testA fails, and will be retried after testB, it will fail.
In a perfect world you control wole test env, but this is not always a case with more complex integrations.
Changing design pattern to always use
beforeEach{enable feature A}
would cost run time (preparation steps sometimes take more than test itself)Example
jest.retryTimes(3, {logErrorsBeforeRetry: true, retryFast: true});
Pitch
WIth more complex preparation steps OR when state of one test depends on another test, retrying at the end of testSuite is more risky. Option to retry just after the test - feels safer. This would add more versality for a different uses cases.
Since retry mechanism is already in the core, this feels like natural extensions.
The text was updated successfully, but these errors were encountered: