Pool Personalizado

WARNING

Esta es una API avanzada y de muy bajo nivel. Si solo necesitas ejecutar pruebas, es probable que no la necesites. Se utiliza principalmente por desarrolladores de bibliotecas.

Vitest ejecuta pruebas en pools. Por defecto, existen varios pools:

• threads para ejecutar pruebas usando node:worker_threads (el aislamiento se proporciona con un nuevo contexto de worker)
• forks para ejecutar pruebas usando node:child_process (el aislamiento se proporciona con un nuevo proceso child_process.fork)
• vmThreads para ejecutar pruebas usando node:worker_threads (pero el aislamiento se proporciona con el módulo vm en lugar de un nuevo contexto de worker)
• browser para ejecutar pruebas usando proveedores de navegadores
• typescript para ejecutar la verificación de tipos en las pruebas

Puedes proporcionar tu propio pool especificando una ruta de archivo de configuración:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    // Ejecutará cada archivo por defecto con un pool personalizado
    pool: './my-custom-pool.ts',
    // Puedes proporcionar opciones mediante el objeto `poolOptions`
    poolOptions: {
      myCustomPool: {
        customProperty: true,
      },
    },
  },
});

Si necesitas ejecutar pruebas en diferentes pools, usa la característica projects:

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

API

El archivo especificado en la opción pool debe exportar una función (puede ser asíncrona) que acepte la interfaz Vitest como su primer argumento. Esta función debe retornar un objeto que cumpla con la interfaz 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 función solo se invoca una vez (a menos que se actualice la configuración del servidor), y generalmente es una buena idea inicializar todo lo necesario para las pruebas dentro de esa función y reutilizarlo cuando se llama a runTests.

Vitest llama a runTests cuando se programan nuevas pruebas para ejecución. No la invocará si files está vacío. El primer argumento es un arreglo de TestSpecifications. Los archivos se ordenan usando sequencer antes de que se llame a runTests. Es posible (pero improbable) tener el mismo archivo duplicado, pero siempre tendrá un proyecto diferente; esto se implementa mediante la configuración de projects.

Vitest esperará hasta que se ejecute runTests antes de finalizar una corrida de pruebas (es decir, emitirá onFinished solo después de que runTests se resuelva).

Si estás utilizando un pool personalizado, deberás proporcionar los archivos de prueba y sus resultados por tu cuenta; puedes consultar vitest.state para ello (los más relevantes son collectFiles y updateTasks). Vitest utiliza la función startTests del paquete @vitest/runner para hacerlo.

Vitest llamará a collectTests si se invoca vitest.collect o si se ejecuta vitest list a través de un comando CLI. Funciona de la misma manera que runTests, pero no tienes que ejecutar los callbacks de prueba, solo reportar sus tareas mediante vitest.state.collectFiles(files).

Para la comunicación entre diferentes procesos, puedes crear un objeto con métodos usando createMethodsRPC de vitest/node, y usar cualquier forma de comunicación que prefieras. Por ejemplo, para usar WebSockets con birpc puedes escribir algo como esto:

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

Puedes ver un ejemplo simple de un pool hecho desde cero que no ejecuta pruebas pero las marca como recolectadas en pool/custom-pool.ts.