Пользовательский пул

WARNING

Это продвинутый API крайне низкого уровня. Если вы просто хотите запустить тесты, вам, вероятно, это не понадобится. Он в основном используется авторами библиотек.

Vitest запускает тесты в пулах. По умолчанию существует несколько пулов:

• threads для запуска тестов с использованием node:worker_threads (изоляция обеспечивается новым контекстом воркера)
• forks для запуска тестов с использованием node:child_process (изоляция обеспечивается новым процессом через child_process.fork)
• vmThreads для запуска тестов с использованием node:worker_threads (но изоляция обеспечивается модулем vm вместо нового контекста воркера)
• browser для запуска тестов с использованием браузерных провайдеров
• typescript для проверки типов тестов

Вы можете предоставить свой собственный пул, указав путь к файлу:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    // по умолчанию все файлы будут запускаться с кастомным пулом
    pool: './my-custom-pool.ts',
    // вы можете предоставить опции, используя объект `poolOptions`
    poolOptions: {
      myCustomPool: {
        customProperty: true,
      },
    },
  },
});

Если вам нужно запускать тесты в разных пулах, используйте функцию projects:

export default defineConfig({
  test: {
    projects: [
      {
        extends: true,
        test: {
          pool: 'threads',
        },
      },
    ],
  },
});

API

Файл, указанный в опции pool, должен экспортировать (может быть асинхронную) функцию, которая принимает интерфейс Vitest в качестве первого аргумента. Эта функция должна возвращать объект, реализующий интерфейс ProcessPool:

import type { ProcessPool, TestSpecification } from 'vitest/node';

export interface ProcessPool {
  name: string;
  runTests: (
    files: TestSpecification[],
    invalidates?: string[]
  ) => Promise<void>;
  collectTests: (
    files: TestSpecification[],
    invalidates?: string[]
  ) => Promise<void>;
  close?: () => Promise<void>;
}

Функция вызывается только один раз (если конфигурация сервера не обновлялась), и, как правило, хорошей идеей является инициализация всего необходимого для тестов внутри этой функции и повторное использование при вызове runTests.

Vitest вызывает runTests, когда запланированы новые тесты. Он не будет вызывать его, если files пуст. Первый аргумент — это массив TestSpecifications. Файлы сортируются с использованием sequencer перед вызовом runTests. Возможно (но маловероятно) наличие одного и того же файла дважды, но он всегда будет принадлежать другому проекту — это реализуется через конфигурацию projects.

Vitest будет ждать выполнения runTests перед завершением запуска (т.е. он вызовет onFinished только после завершения runTests).

Если вы используете кастомный пул, вам придется самостоятельно обеспечивать тестовые файлы и их результаты — вы можете обратиться к vitest.state для этого (наиболее важными являются collectFiles и updateTasks). Vitest использует функцию startTests из пакета @vitest/runner для этого.

Vitest вызовет collectTests, если будет вызван vitest.collect или vitest list через команду CLI. Это работает так же, как runTests, но вам не нужно вызывать колбэки тестов, только сообщать об их задачах, вызывая vitest.state.collectFiles(files).

Для связи между различными процессами вы можете создать объект методов, используя createMethodsRPC из vitest/node, и использовать любой предпочтительный способ связи. Например, для использования WebSockets с birpc вы можете написать что-то вроде этого:

import { createBirpc } from 'birpc';
import { parse, stringify } from 'flatted';
import { createMethodsRPC, TestProject } from 'vitest/node';

function createRpc(project: TestProject, wss: WebSocketServer) {
  return createBirpc(createMethodsRPC(project), {
    post: msg => wss.send(msg),
    on: fn => wss.on('message', fn),
    serialize: stringify,
    deserialize: parse,
  });
}

Вы можете увидеть простой пример пула, созданного с нуля, который не запускает тесты, но отмечает их как собранные, в pool/custom-pool.ts.