tests: better target tests through vitest and set default browser config #1619
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm PoCing a common config for most kinds of tests in the RxPlayer (integration, memory and unit tests, so we just exclude the very situational "performance" and "conformance" tests).
All three of them are relying on
vitest
but integration+memory tests run in a browser and unit tests run in a jsdom-ed Node.js environment.With the goal of performing every tests in a web browser/user-agent to better reflect actual RxPlayer usage (in production, we need to run on something that has HTML5 video/audio and preferably EME+MSE, so Node.js isn't a realist target today) and of having the simplicity of just being able to call
npx vitest
to run all those tests with a common environment, I'm currently updatingvitest
configs and unit tests.This PR is an offshoot of that work that is compatible to what we already do today:
vitest
's config more explicitly include memory+integration tests.I added a default browser (sadly, I chose here Chrome, for popularity and universality reasons) for when no browser is asked for (this is only useful when calling
npx vitest
directly, which we never do but which a developer could want to do - in which case running all tests in chrome would be better than just failing randomly).