vitest-dev
Add describe.parallel to run tests in parallel
Clear and concise description of the problem
vitest already has describe.concurrent which runs tests concurrently within the same worker. Test are not run in isolation then.
Suggested solution
describe.parallel would also run tests in parallel but with full isolation of each test as if each test had been placed into its own spec-file. So each test is run in its own worker, beforeAll is run for each test, etc.
See #1530 for some more motivation and discussion.
Alternative
Alternative 1: The semantics of describe.concurrent could be changed to match the desired behaviour. One could argue that the current behaviour does not fit vitest's mental model of test execution wrt isolation.
Alternative 2: Add a switch to describe.concurrent like this:
describe.concurrent("Tests", () => {
...
}, {isolation: true})
With this approach it would be easy to change the default behaviour to isolation: true or have a configuration variable control the default behaviour. This would have the benefit of not introducing a new API with a confusing name (concurrent vs parallel).
Alternative 3: Only have a configuration switch.
Additional context
No response
Validations
- [X] Follow our Code of Conduct
- [X] Read the Contributing Guidelines.
- [X] Read the docs.
- [X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
Why not just make this behavior default? I'd love to have all my tests run in a separate clean worker thread. I think it might be better to make this a global config?
Why not just make this behavior default? I'd love to have all my tests run in a separate clean worker thread. I think it might be better to make this a global config?
- You tests will be unbearably slow. Right now firing up an isolated worker takes the most of the time, when running Vitest. Imaging firing worker for each test.
- Your local global namespace will be screwed. Making changes to local variables cases a lot of confusion, because the changes won't be reflected in your tests.
I think only if people understand the underlying behaviour, we can make it a default/config option. I would prefer if people were using separate files as isolation tool, since it's much more approachable.
Just adding a use case as motivation: I have a single test file that loads a large number of test cases from data files. I'd like to run those in parallel, chunked in some data-driven way. Creating separate files for parallel execution isn't an option with data-driven tests, and there's no clear way to create a custom worker thread for this purpose, since the entry point for a worker thread has to be a JS file—and doesn't support importing TS/Svelte/etc.
After the discussion with the team, we think that this feature is out of the scope of Vitest. Running test callbacks in separate threads creates a lot of confusion (because they don't have access to the same variables), tanks your performance, and introduces a lot of complexity.
What we can support is running virtual tests, but this would require designing a new API. If you think this is a worthwhile feature, please open a separate issue.