Руководство по миграции

Миграция с Jest

Vitest разработан с API, совместимым с Jest, чтобы максимально упростить миграцию. Несмотря на это, вы все равно можете столкнуться со следующими различиями:

Глобальные объекты по умолчанию

В Jest глобальные API доступны по умолчанию. В Vitest это не так. Вы можете либо включить глобальные переменные через настройку конфигурации globals, либо обновить код для использования импортов из модуля vitest.

Если вы решите оставить глобальные переменные отключенными, учтите, что общие библиотеки, такие как testing-library, не будут автоматически выполнять очистку DOM.

Мокирование модулей

При мокировании модуля в Jest возвращаемое значение функции, переданной в аргумент factory, является экспортом по умолчанию. В Vitest аргумент factory должен возвращать объект с явно определенными экспортами. Например, следующий jest.mock необходимо обновить:

- jest.mock('./some-path', () => 'hello')
+ vi.mock('./some-path', () => ({
+   default: 'hello',
+ })

Подробнее см. в разделе API vi.mock.

Поведение автоматического создания mock-объектов

В отличие от Jest, замокированные модули, расположенные в <root>/__mocks__, не загружаются автоматически, если не вызван vi.mock(). Если вам нужно, чтобы они были замокированы в каждом тесте, как в Jest, вы можете мокировать их внутри setupFiles.

Импорт оригинала мокированного пакета

Если вы частично мокируете пакет, то ранее могли использовать функцию requireActual в Jest. В Vitest вам следует заменить эти вызовы на vi.importActual.

- const { cloneDeep } = jest.requireActual('lodash/cloneDeep')
+ const { cloneDeep } = await vi.importActual('lodash/cloneDeep')

Переменные окружения

Как и Jest, Vitest устанавливает NODE_ENV в test, если он не был установлен ранее. Vitest также имеет аналог для JEST_WORKER_ID под названием VITEST_POOL_ID (всегда меньше или равно maxThreads). Если вы полагаетесь на эту переменную, не забудьте ее переименовать. Vitest также предоставляет VITEST_WORKER_ID, который является уникальным идентификатором рабочего процесса (worker). Это число не зависит от maxThreads и будет увеличиваться с каждым созданным worker'ом.

Если вы хотите изменить переменные окружения, используя replaceProperty API в Jest, вы можете использовать vi.stubEnv в Vitest.

Обратный вызов Done

Начиная с Vitest v0.10.0, стиль объявления тестов с использованием callback считается устаревшим. Вы можете переписать их для использования функций async/await или использовать Promise, чтобы имитировать стиль callback.

- it('should work', (done) => {
+ it('should work', () => new Promise(done => {
    // ...
    done()
- })
+ }))

Хуки (hooks)

Хуки beforeAll/beforeEach могут возвращать функцию очистки в Vitest. Из-за этого вам может потребоваться переписать объявления хуков, если они возвращают что-либо, отличное от undefined или null:

- beforeEach(() => setActivePinia(createTestingPinia()))
+ beforeEach(() => { setActivePinia(createTestingPinia()) })

Типы

Vitest не предоставляет много типов в пространстве Vi. Оно существует в основном для совместимости с matchers, поэтому вам может потребоваться импортировать типы непосредственно из vitest, а не полагаться на пространство Vi:

- let fn: jest.Mock<string, [string]>
+ import type { Mock } from 'vitest'
+ let fn: Mock<[string], string>

Кроме того, в Vitest тип Args является первым аргументом, а не Returns, как показано в примере diff.

Таймеры

Vitest не поддерживает унаследованные таймеры Jest.

Снимки Vue (snapshots)

Это не специфическая для Jest функция, но если вы ранее использовали Jest с vue-cli preset, вам нужно будет установить пакет jest-serializer-vue и использовать его внутри setupFiles:

vite.config.js

import { defineConfig } from 'vite';

export default defineConfig({
  test: {
    setupFiles: ['./tests/unit/setup.js'],
  },
});

tests/unit/setup.js

import vueSnapshotSerializer from 'jest-serializer-vue';

expect.addSnapshotSerializer(vueSnapshotSerializer);

В противном случае в ваших снимках будет много экранированных символов ".