Pool Personalizado

WARNING

Esta é uma API avançada e de nível muito baixo. Se você apenas deseja executar testes, provavelmente não precisa dela. Ela é usada principalmente por autores de bibliotecas.

O Vitest executa testes em pools. Por padrão, existem vários pools:

• threads para executar testes usando node:worker_threads (o isolamento é fornecido por um novo contexto de worker)
• forks para executar testes usando node:child_process (o isolamento é fornecido por um novo processo child_process.fork)
• vmThreads para executar testes usando node:worker_threads (mas o isolamento é fornecido pelo módulo vm em vez de um novo contexto de worker)
• browser para executar testes usando provedores de navegador
• typescript para executar verificação de tipos nos testes

Você pode fornecer seu próprio pool especificando um caminho de arquivo:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    // executará cada arquivo com um pool personalizado por padrão
    pool: './my-custom-pool.ts',
    // você pode passar opções usando o objeto `poolOptions`
    poolOptions: {
      myCustomPool: {
        customProperty: true,
      },
    },
  },
});

Se você precisar executar testes em pools diferentes, use o recurso projects:

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

API

O arquivo especificado na opção pool deve exportar uma função (pode ser assíncrona) que aceita a interface Vitest como seu primeiro argumento. Esta função precisa retornar um objeto que implemente a interface 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>;
}

A função é chamada apenas uma vez (a menos que a configuração do servidor seja atualizada), e geralmente é uma boa ideia inicializar tudo o que você precisa para os testes dentro dessa função e reutilizar isso quando runTests for chamado.

O Vitest chama runTests quando novos testes são agendados para execução. Ele não a chamará se files estiver vazio. O primeiro argumento é um array de TestSpecifications. Os arquivos são ordenados usando sequencer antes que runTests seja chamado. É possível (mas improvável) ter o mesmo arquivo duas vezes, mas cada instância sempre terá um projeto diferente - isso é implementado via configuração projects.

O Vitest aguardará até que runTests seja executado antes de finalizar a execução (ou seja, ele emitirá onFinished somente depois que runTests for resolvido).

Se você estiver usando um pool personalizado, terá que fornecer os arquivos de teste e seus resultados você mesmo - você pode consultar vitest.state para isso (os mais importantes são collectFiles e updateTasks). O Vitest usa a função startTests do pacote @vitest/runner para fazer isso.

O Vitest chamará collectTests se vitest.collect for chamado ou vitest list for invocado por meio de um comando CLI. Funciona da mesma forma que runTests, mas você não precisa executar callbacks de teste, apenas registrar suas tarefas chamando vitest.state.collectFiles(files).

Para se comunicar entre diferentes processos, você pode criar um objeto com métodos usando createMethodsRPC de vitest/node, e usar qualquer forma de comunicação que preferir. Por exemplo, para usar WebSockets com birpc você pode escrever o seguinte:

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

Você pode ver um exemplo simples de um pool implementado do zero que não executa testes, mas os marca como coletados em pool/custom-pool.ts.