Benutzerdefinierter Pool

WARNING

Dies ist eine fortgeschrittene und sehr grundlegende API. Wenn Sie lediglich Tests ausführen möchten, werden Sie dies wahrscheinlich nicht benötigen. Sie findet hauptsächlich bei Bibliotheksautoren Anwendung.

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

• threads zum Ausführen von Tests mit node:worker_threads (Isolation wird mittels eines neuen Worker-Kontexts gewährleistet)
• forks zum Ausführen von Tests mit node:child_process (Isolation wird mittels eines neuen child_process.fork-Prozesses gewährleistet)
• vmThreads zum Ausführen von Tests mit node:worker_threads (die Isolation wird jedoch durch das vm-Modul anstelle eines neuen Worker-Kontexts gewährleistet)
• browser zum Ausführen von Tests mit Browser-Providern
• typescript zur Typüberprüfung von Tests

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

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    // Führt standardmäßig jede Datei in einem benutzerdefinierten Pool aus
    pool: './my-custom-pool.ts',
    // Optionen können Sie über das Objekt `poolOptions` angeben
    poolOptions: {
      myCustomPool: {
        customProperty: true,
      },
    },
  },
});

Wenn Sie Tests in verschiedenen Pools ausführen müssen, verwenden Sie die projects-Funktionalität:

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

API

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

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

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

Vitest ruft runTests auf, sobald neue Tests zur Ausführung anstehen. Die Funktion wird nicht aufgerufen, wenn files leer ist. Das erste Argument ist ein Array von TestSpecifications. Dateien werden mittels sequencer sortiert, bevor runTests aufgerufen wird. Es ist möglich (wenn auch unwahrscheinlich), dass dieselbe Datei zweimal vorkommt. In diesem Fall wird sie jedoch immer einem anderen Projekt zugeordnet sein – dies wird über die projects-Konfiguration implementiert.

Vitest wartet, bis runTests ausgeführt wurde, bevor ein Testlauf abgeschlossen wird (d.h., onFinished wird erst nach der Auflösung von runTests ausgelöst).

Wenn Sie einen benutzerdefinierten Pool verwenden, müssen Sie Testdateien und deren Ergebnisse selbst bereitstellen. Hierfür können Sie sich auf vitest.state beziehen (besonders relevant sind collectFiles und updateTasks). Vitest verwendet hierfür die Funktion startTests aus dem Paket @vitest/runner.

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

Um zwischen verschiedenen Prozessen zu kommunizieren, können Sie ein RPC-Methodenobjekt mit createMethodsRPC aus vitest/node erstellen und jede bevorzugte Kommunikationsform verwenden. Beispielsweise können Sie für WebSockets mit birpc Folgendes schreiben:

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

Ein einfaches Beispiel für einen selbst erstellten Pool, der Tests nicht ausführt, sondern lediglich als gesammelt markiert, finden Sie unter pool/custom-pool.ts.