vitest-dev / vitest-dev/vitest
Run failed tests in a clean environment on retry
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 17.1k
- Forks
- 2k
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 92
Description
Clear and concise description of the problem
When using retry on a failing test, tests are re-run within the same runtime environment. However, many intermittent or flaky tests (especially those involving side effects, DOM manipulation, async operations, or mocked dependencies) require a full environment reset to succeed. Re-running in the same context doesn’t help when the failure stems from shared or mutated state, event listeners, or global mocks that need cleanup.
Suggested solution
Introduce a new option (e.g., --retry-isolated, --retry-clean, or --reload-on-retry) that allows Vitest to:
1. Detect failing tests on the first run.
2. For each failed test (or test file), spawn a new isolated Vitest process to re-run only those tests.
3. Report the combined result of both runs, clearly indicating which tests passed only on retry.
Alternative
Without built in support, users must:
• Run the test suite with a reporter that outputs failed test names
• Parse the output manually
• Re-run Vitest, filtering for the tests that failed
However, where this would be most helpful is in CI environments, where these types of failures introduce a significant delay
Additional context
This is particularly valuable in CI environments and with UI feature / integration tests that rely on mocked endpoints and DOM queries.
Validations
- Follow our Code of Conduct
- Read the Contributing Guidelines.
- Read the docs.
- Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the existing retry configuration and the reporter or test-filtering behavior referenced in the issue. Trace how failed tests are selected and rerun, then define the isolated-process flow and combined reporting; done means failed tests can be retried in a clean environment and the result distinguishes first-run failures from retry-only passes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- testing-qa
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100