Melhorando o Desempenho

Isolamento de Teste

Por padrão, o Vitest executa cada arquivo de teste em um ambiente isolado, com base no pool configurado:

• O pool threads executa cada arquivo de teste em um Worker distinto.
• O pool forks executa cada arquivo de teste em um processo filho separado.
• O pool vmThreads executa cada arquivo de teste em um contexto VM distinto, mas utiliza workers para paralelismo.

O isolamento pode aumentar significativamente o tempo de execução dos testes. Para projetos que não dependem de efeitos colaterais e que realizam a limpeza adequada de seu estado (o que geralmente ocorre em projetos com ambiente node), desabilitar o isolamento pode melhorar a velocidade dos testes. Para isso, você pode usar a flag --no-isolate na CLI ou definir a propriedade test.isolate como false na configuração.

CLI

vitest --no-isolate

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    isolate: false,
    // Você também pode desabilitar o isolamento apenas para pools específicos
    poolOptions: {
      forks: {
        isolate: false,
      },
    },
  },
});

TIP

Se você estiver usando o pool vmThreads, não será possível desabilitar o isolamento. Para melhorar o desempenho dos seus testes, considere usar o pool threads em vez disso.

Para alguns projetos, pode ser desejável desabilitar o paralelismo para melhorar o tempo de inicialização. Para fazer isso, forneça a flag --no-file-parallelism para a CLI ou defina a propriedade test.fileParallelism na configuração como false.

CLI

vitest --no-file-parallelism

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    fileParallelism: false,
  },
});

Pool

Por padrão, o Vitest executa testes no pool: 'forks'. Embora o pool 'forks' seja mais adequado para resolver problemas de compatibilidade (como processos que travam e segfaults), ele pode ser um pouco mais lento que pool: 'threads' em projetos maiores.

Você pode tentar melhorar o tempo de execução dos testes alterando a opção pool na configuração:

CLI

vitest --pool=threads

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    pool: 'threads',
  },
});

Sharding

O sharding de testes é o processo de dividir sua suíte de testes em grupos, ou shards. Isso pode ser útil quando você tem um grande conjunto de testes e múltiplas máquinas que podem executar subconjuntos dessa suíte simultaneamente.

Para dividir os testes do Vitest em várias execuções diferentes, use a opção --shard em conjunto com a opção --reporter=blob:

vitest run --reporter=blob --shard=1/3 # 1ª máquina
vitest run --reporter=blob --shard=2/3 # 2ª máquina
vitest run --reporter=blob --shard=3/3 # 3ª máquina

O Vitest divide seus arquivos de teste, e não seus casos de teste, em shards. Se você tiver 1000 arquivos de teste, a opção --shard=1/4 executará 250 arquivos de teste, independentemente de quantos casos de teste os arquivos individuais contenham.

Colete os resultados armazenados no diretório .vitest-reports de cada máquina e mescle-os com a opção --merge-reports:

vitest run --merge-reports

Exemplo de ação do Github

Esta configuração também é utilizada em https://github.com/vitest-tests/test-sharding.

# Inspirado em https://playwright.dev/docs/test-sharding
name: Tests
on:
  push:
    branches:
      - main
jobs:
  tests:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        shardIndex: [1, 2, 3, 4]
        shardTotal: [4]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install pnpm
        uses: pnpm/action-setup@a7487c7e89a18df4991f7f222e4898a00d66ddda # v4.1.0

      - name: Install dependencies
        run: pnpm i

      - name: Run tests
        run: pnpm run test --reporter=blob --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }}

      - name: Upload blob report to GitHub Actions Artifacts
        if: ${{ !cancelled() }}
        uses: actions/upload-artifact@v4
        with:
          name: blob-report-${{ matrix.shardIndex }}
          path: .vitest-reports/*
          include-hidden-files: true
          retention-days: 1

  merge-reports:
    if: ${{ !cancelled() }}
    needs: [tests]

    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install pnpm
        uses: pnpm/action-setup@a7487c7e89a18df4991f7f222e4898a00d66ddda # v4.1.0

      - name: Install dependencies
        run: pnpm i

      - name: Download blob reports from GitHub Actions Artifacts
        uses: actions/download-artifact@v4
        with:
          path: .vitest-reports
          pattern: blob-report-*
          merge-multiple: true

      - name: Merge reports
        run: npx vitest --merge-reports

TIP

O sharding de testes também pode ser útil em máquinas com alta contagem de CPUs.

O Vitest executará apenas um único servidor Vite em sua thread principal. As demais threads são utilizadas para executar arquivos de teste. Em uma máquina com alta contagem de CPU, a thread principal pode se tornar um gargalo, pois pode não conseguir processar todas as solicitações vindas das threads de teste. Por exemplo, em uma máquina de 32 CPUs, a thread principal é responsável por lidar com a carga proveniente de 31 threads de teste.

Para reduzir a carga do servidor Vite na thread principal, você pode usar o sharding de testes. A carga pode ser balanceada em vários servidores Vite.

# Exemplo para dividir testes em 32 CPUs em 4 shards.
# Como cada processo requer 1 thread principal, restam 7 threads para os executores de teste (1+7)*4 = 32
# Use VITEST_MAX_THREADS ou VITEST_MAX_FORKS dependendo do pool:
VITEST_MAX_THREADS=7 vitest run --reporter=blob --shard=1/4 & \
VITEST_MAX_THREADS=7 vitest run --reporter=blob --shard=2/4 & \
VITEST_MAX_THREADS=7 vitest run --reporter=blob --shard=3/4 & \
VITEST_MAX_THREADS=7 vitest run --reporter=blob --shard=4/4 & \
wait # https://man7.org/linux/man-pages/man2/waitpid.2.html

vitest run --merge-reports