Niestandardowa pula

WARNING

Jest to zaawansowane i bardzo niskopoziomowe API. Jeśli chcesz po prostu uruchomić testy, prawdopodobnie nie potrzebujesz tego. Jest ono używane głównie przez autorów bibliotek.

Vitest uruchamia testy w pulach. Domyślnie dostępnych jest kilka pul:

• threads do uruchamiania testów za pomocą node:worker_threads (izolacja zapewniana jest przez nowy kontekst workera)
• forks do uruchamiania testów za pomocą node:child_process (izolacja jest zapewniona przez nowy proces child_process.fork)
• vmThreads do uruchamiania testów za pomocą node:worker_threads (ale izolacja jest zapewniona przez moduł vm zamiast nowego kontekstu workera)
• browser do uruchamiania testów za pomocą dostawców środowisk przeglądarkowych
• typescript do uruchamiania sprawdzania typów testów

Możesz dostarczyć własną pulę, określając ścieżkę pliku:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    // Domyślnie każdy plik będzie uruchamiany z niestandardową pulą.
    pool: './my-custom-pool.ts',
    // Możesz podać opcje za pomocą obiektu `poolOptions`.
    poolOptions: {
      myCustomPool: {
        customProperty: true,
      },
    },
  },
});

Jeśli potrzebujesz uruchomić testy w różnych pulach, użyj funkcji projects:

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

API

Plik określony w opcji pool powinien eksportować funkcję (może być asynchroniczna), która przyjmuje interfejs Vitest jako swój pierwszy argument. Ta funkcja musi zwracać obiekt pasujący do interfejsu 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>;
}

Funkcja jest wywoływana tylko raz (chyba że konfiguracja serwera została zaktualizowana). Ogólnie zaleca się zainicjowanie wszystkiego, czego potrzebujesz do testów, wewnątrz tej funkcji i ponowne użycie tego, gdy wywoływana jest runTests.

Vitest wywołuje runTests, gdy nowe testy są zaplanowane do uruchomienia. Nie wywoła tej funkcji, jeśli files są puste. Pierwszy argument to tablica TestSpecifications. Pliki są sortowane za pomocą sequencer przed wywołaniem runTests. Możliwe jest (choć mało prawdopodobne) występowanie tego samego pliku dwukrotnie, ale zawsze będzie on należał do innego projektu – jest to zaimplementowane za pomocą konfiguracji projects.

Vitest będzie czekał, aż runTests zostanie wykonane, zanim zakończy przebieg testów (tj. wyemituje onFinished dopiero po rozstrzygnięciu runTests).

Jeśli używasz niestandardowej puli, będziesz musiał samodzielnie zapewnić pliki testowe i ich wyniki – możesz odnieść się do vitest.state w tym celu (najistotniejsze są collectFiles i updateTasks). Vitest używa funkcji startTests z pakietu @vitest/runner do tego celu.

Vitest wywoła collectTests, jeśli vitest.collect zostanie wywołane lub vitest list zostanie uruchomione za pomocą polecenia CLI. Działa to tak samo jak runTests, ale nie musisz uruchamiać funkcji zwrotnych testów, a jedynie rejestrować ich zadania, wywołując vitest.state.collectFiles(files).

Aby komunikować się pomiędzy różnymi procesami, możesz utworzyć obiekt z metodami za pomocą createMethodsRPC z vitest/node i użyć dowolnej preferowanej formy komunikacji. Na przykład, aby użyć WebSockets z birpc, możesz napisać coś takiego:

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,
  });
}

Możesz zobaczyć prosty przykład puli utworzonej od podstaw, która nie uruchamia testów, lecz oznacza je jako zebrane w pool/custom-pool.ts.