Migration Guide
Migrating from Jest
Vitest has been designed with a Jest compatible API, in order to make the migration from Jest as simple as possible. Despite those efforts, you may still run into the following differences:
Globals as a Default
Jest has their globals API enabled by default. Vitest does not. You can either enable globals via the globals
configuration setting or update your code to use imports from the vitest
module instead.
If you decide to keep globals disabled, be aware that common libraries like testing-library
will not run auto DOM cleanup.
Auto-Mocking Behaviour
Unlike Jest, mocked modules in <root>/__mocks__
are not loaded unless vi.mock()
is called. If you need them to be mocked in every test, like in Jest, you can mock them inside setupFiles
.
Mocking globals
In Jest, you could mock global variables by putting them on window
object. Vitest treats globalThis
and window
as different objects, so you would need to either put it on both window
and globalThis
, or use vi.stubGlobal
helper.
Jasmine API
Jest exports various jasmine
globals (such as jasmine.any()
). Any such instances will need to be migrated to their Vitest counterparts.
Envs
Just like Jest, Vitest sets NODE_ENV
to test
, if it wasn't set before. Vitest also has a counterpart for JEST_WORKER_ID
called VITEST_WORKER_ID
, so if you rely on it, don't forget to rename it.
Done Callback
From Vitest v0.10.0, the callback style of declaring tests is deprecated. You can rewrite them to use async
/await
functions, or use Promise to mimic the callback style.
- it('should work', (done) => {
+ it('should work', () => new Promise(done => {
// ...
done()
- })
+ }))