Migliorare le prestazioni

Isolamento dei test

Per impostazione predefinita, Vitest esegue ogni file di test in un ambiente isolato, in base al pool configurato:

• Il pool threads esegue ogni file di test in un Worker separato.
• Il pool forks esegue ogni file di test in un processo figlio fork separato.
• Il pool vmThreads esegue ogni file di test in un contesto VM separato, ma utilizza i worker per il parallelismo.

L'isolamento può aumentare significativamente i tempi di esecuzione dei test. Questo potrebbe non essere desiderabile per progetti che non si basano su effetti collaterali e che gestiscono correttamente la pulizia del loro stato (il che è solitamente vero per i progetti con un ambiente node). In questi casi, disabilitare l'isolamento può migliorare la velocità dei test. Per farlo, puoi utilizzare il flag --no-isolate dalla CLI o impostare la proprietà test.isolate nella configurazione su false. Se stai utilizzando più pool in parallelo con poolMatchGlobs, puoi anche disabilitare l'isolamento per un pool specifico.

CLI

vitest --no-isolate

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    isolate: false,
    // Puoi anche disabilitare l'isolamento solo per pool specifici
    poolOptions: {
      forks: {
        isolate: false,
      },
    },
  },
});

TIP

Se stai utilizzando il pool vmThreads, non è possibile disabilitare l'isolamento. Per migliorare le prestazioni dei tuoi test, considera l'uso del pool threads in alternativa.

Per alcuni progetti, potrebbe essere preferibile disabilitare il parallelismo per migliorare i tempi di avvio. Per farlo, fornisci il flag --no-file-parallelism alla CLI o imposta la proprietà test.fileParallelism nella configurazione su false.

CLI

vitest --no-file-parallelism

vitest.config.js

import { defineConfig } from 'vitest/config';

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

Pool

Per impostazione predefinita, Vitest esegue i test nel pool: 'forks'. Sebbene il pool 'forks' sia preferibile per problemi di compatibilità (come processi in stallo e segfaults), potrebbe essere leggermente più lento di pool: 'threads' in progetti di grandi dimensioni.

Puoi provare a migliorare il tempo di esecuzione dei test modificando l'opzione pool nella configurazione:

CLI

vitest --pool=threads

vitest.config.js

import { defineConfig } from 'vitest/config';

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

Sharding

Lo sharding dei test consiste nell'eseguire un piccolo sottoinsieme di casi di test alla volta. Questa tecnica è utile quando si dispone di più macchine che possono essere utilizzate per eseguire i test contemporaneamente.

Per dividere i test Vitest su più esecuzioni diverse, usa l'opzione --shard insieme all'opzione --reporter=blob:

vitest run --reporter=blob --shard=1/3 # 1ª macchina
vitest run --reporter=blob --shard=2/3 # 2ª macchina
vitest run --reporter=blob --shard=3/3 # 3ª macchina

Raccogli i risultati salvati nella directory .vitest-reports da ogni macchina e uniscili con l'opzione --merge-reports:

vitest --merge-reports

Esempio di azione Github

Questa configurazione è utilizzata anche in https://github.com/vitest-tests/test-sharding.

# Ispirato a 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@v4

      - 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@v4

      - 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

Lo sharding dei test può rivelarsi utile anche su macchine con molte CPU.

Vitest eseguirà un solo server Vite nel suo thread principale, mentre i thread rimanenti vengono utilizzati per eseguire i file di test. In una macchina con un elevato numero di CPU, il thread principale può diventare un collo di bottiglia, poiché potrebbe non essere in grado di gestire tutte le richieste provenienti dai thread. Ad esempio, in una macchina a 32 CPU, il thread principale è responsabile della gestione del carico proveniente da 31 thread di test.

Per ridurre il carico sul server Vite del thread principale, puoi usare lo sharding dei test. Il carico può essere bilanciato su più server Vite.

# Esempio per dividere i test su 32 CPU in 4 shard.
# Poiché ogni processo necessita di 1 thread principale, ci sono 7 thread per i runner di test (1+7)*4 = 32
# Usa VITEST_MAX_THREADS o VITEST_MAX_FORKS a seconda del 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 --merge-reports