Pool Personalizzato

WARNING

Questa è un'API avanzata e di basso livello. Se desideri semplicemente eseguire i test, probabilmente non ne hai bisogno. È utilizzata principalmente dagli autori di librerie.

Vitest esegue i test utilizzando i pool. Per impostazione predefinita, sono disponibili diversi pool:

• threads per eseguire i test usando node:worker_threads (l'isolamento è fornito da un nuovo contesto worker)
• forks per eseguire i test usando node:child_process (l'isolamento è fornito da un nuovo processo child_process.fork)
• vmThreads per eseguire i test usando node:worker_threads (ma l'isolamento è fornito dal modulo vm anziché da un nuovo contesto worker)
• browser per eseguire i test usando i provider del browser
• typescript per eseguire il controllo dei tipi sui test

Puoi definire il tuo pool specificando un percorso di file:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    // per impostazione predefinita, ogni file verrà eseguito con un pool personalizzato
    pool: './my-custom-pool.ts',
    // puoi fornire opzioni utilizzando l'oggetto `poolOptions`
    poolOptions: {
      myCustomPool: {
        customProperty: true,
      },
    },
  },
});

Se hai bisogno di eseguire i test in pool diversi, utilizza la funzionalità projects:

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

API

Il file specificato nell'opzione pool deve esportare una funzione (che può essere asincrona) che accetta l'interfaccia Vitest come primo argomento. Questa funzione deve restituire un oggetto che corrisponde all'interfaccia 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>;
}

La funzione viene invocata una sola volta (a meno che la configurazione del server non venga aggiornata), ed è buona norma inizializzare tutto ciò di cui hai bisogno per i test all'interno di quella funzione e riutilizzare quanto inizializzato quando viene chiamato runTests.

Vitest chiama runTests quando nuovi test sono pianificati per l'esecuzione. Non verrà chiamato se files è vuoto. Il primo argomento è un array di TestSpecifications. I file sono ordinati tramite sequencer prima che runTests venga chiamato. È possibile (sebbene improbabile) avere lo stesso file due volte, ma in tal caso avrà sempre un progetto diverso - questo è implementato tramite la configurazione projects.

Vitest attenderà che runTests venga completato prima di terminare l'esecuzione (cioè, emetterà onFinished solo dopo la risoluzione di runTests).

Se utilizzi un pool personalizzato, dovrai fornire autonomamente i file di test e i relativi risultati - puoi consultare vitest.state per questo (le più rilevanti sono collectFiles e updateTasks). Vitest usa la funzione startTests del pacchetto @vitest/runner per fare ciò.

Vitest chiamerà collectTests se viene invocato vitest.collect o vitest list tramite un comando CLI. Si comporta come runTests, ma non devi eseguire i callback di test; devi solo segnalare le relative attività chiamando vitest.state.collectFiles(files).

Per comunicare tra processi diversi, puoi definire un oggetto di metodi utilizzando createMethodsRPC dal modulo vitest/node e usare qualsiasi forma di comunicazione che preferisci. Ad esempio, per utilizzare WebSockets con birpc puoi implementare una soluzione simile:

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

Puoi vedere un semplice esempio di un pool creato da zero che non esegue test ma li contrassegna come raccolti in pool/custom-pool.ts.