Benutzerdefinierter Pool

WARNING

Dies ist eine fortgeschrittene API. Wenn Sie nur Tests ausführen möchten, benötigen Sie dies wahrscheinlich nicht. Es wird hauptsächlich von Bibliotheksautoren verwendet.

Vitest führt Tests in Pools aus. Standardmäßig gibt es mehrere Pools:

• threads zur Ausführung von Tests mit node:worker_threads (Isolation durch einen neuen Worker-Kontext)
• forks zur Ausführung von Tests mit node:child_process (Isolation durch einen neuen child_process.fork-Prozess)
• vmThreads zur Ausführung von Tests mit node:worker_threads (Isolation durch das vm-Modul anstelle eines neuen Worker-Kontexts)
• browser zur Ausführung von Tests mit Browser-Providern
• typescript zur Durchführung von Typüberprüfungen bei Tests

Sie können einen eigenen Pool definieren, indem Sie einen Dateipfad angeben:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    // Führt standardmäßig jede Datei mit einem benutzerdefinierten Pool aus
    pool: './my-custom-pool.ts',
    // Sie können Optionen mit dem `poolOptions`-Objekt bereitstellen
    poolOptions: {
      myCustomPool: {
        customProperty: true,
      },
    },
    // Sie können auch einen Pool für eine Teilmenge von Dateien angeben
    poolMatchGlobs: [['**/*.custom.test.ts', './my-custom-pool.ts']],
  },
});

API

Die in der Option pool angegebene Datei sollte eine Funktion exportieren (diese kann asynchron sein), die das Vitest-Interface als erstes Argument akzeptiert. Diese Funktion muss ein Objekt zurückgeben, das der ProcessPool-Schnittstelle entspricht:

import { ProcessPool, WorkspaceProject } from 'vitest/node';

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

Die Funktion wird nur einmal aufgerufen (es sei denn, die Serverkonfiguration wurde aktualisiert). Es ist ratsam, alles für Tests Notwendige in dieser Funktion zu initialisieren und bei Aufruf von runTests wiederzuverwenden.

Vitest ruft runTests auf, wenn neue Tests zur Ausführung bereitstehen. Die Funktion wird nicht aufgerufen, wenn files leer ist. Das erste Argument ist ein Array von Tupeln: Das erste Element ist eine Referenz auf ein Workspace-Projekt und das zweite ist ein absoluter Pfad zu einer Testdatei. Dateien werden mit sequencer sortiert, bevor runTests aufgerufen wird. Es ist möglich (aber unwahrscheinlich), dass dieselbe Datei zweimal vorkommt, aber sie wird immer zu einem anderen Projekt gehören - dies wird über die Konfiguration vitest.workspace.ts sichergestellt.

Vitest wartet, bis runTests abgeschlossen ist, bevor ein Durchlauf beendet wird (d. h. onFinished wird erst gesendet, nachdem runTests aufgelöst wurde).

Wenn Sie einen benutzerdefinierten Pool verwenden, müssen Sie Testdateien und ihre Ergebnisse selbst verwalten. Sie können sich dabei auf vitest.state beziehen (besonders wichtig sind collectFiles und updateTasks). Vitest verwendet die Funktion startTests aus dem Paket @vitest/runner, um dies zu tun.

Vitest ruft collectTests auf, wenn vitest.collect aufgerufen wird oder vitest list über einen CLI-Befehl aufgerufen wird. Es funktioniert auf die gleiche Weise wie runTests, aber Sie müssen keine Test-Callbacks ausführen, sondern nur deren Aufgaben melden, indem Sie vitest.state.collectFiles(files) aufrufen.

Um zwischen verschiedenen Prozessen zu kommunizieren, können Sie ein Methodenobjekt mit createMethodsRPC aus vitest/node erstellen und jede beliebige Form der Kommunikation verwenden. Um beispielsweise WebSockets mit birpc zu verwenden, können Sie Folgendes schreiben:

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

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

Um sicherzustellen, dass jeder Test erfasst wird, rufen Sie ctx.state.collectFiles auf und melden Sie dies an die Vitest-Reporter:

async function runTests(project: WorkspaceProject, tests: string[]) {
  // ... running tests, put into "files" and "tasks"
  const methods = createMethodsRPC(project);
  await methods.onCollected(files);
  // most reporters rely on results being updated in "onTaskUpdate"
  await methods.onTaskUpdate(tasks);
}

Ein einfaches Beispiel finden Sie unter pool/custom-pool.ts.