Ottimizzare le Prestazioni

Isolamento dei test

Per impostazione predefinita, Vitest esegue ogni file di test in un ambiente isolato, basandosi sul 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 forked separato.
• Il pool vmThreads esegue ogni file di test in un contesto VM separato, ma utilizza i worker per il parallelismo.

Questo approccio può aumentare significativamente il tempo di esecuzione dei test, il che potrebbe non essere ideale per progetti che non dipendono da effetti collaterali e gestiscono il loro stato in modo appropriato (come spesso accade nei progetti con ambiente node). In questi casi, disabilitare l'isolamento può migliorare la velocità dei test. Per farlo, è possibile utilizzare il flag --no-isolate nella CLI o impostare la proprietà test.isolate nella configurazione su false.

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 si utilizza il pool vmThreads, non è possibile disabilitare l'isolamento. Per migliorare le prestazioni dei test, si consiglia di utilizzare il pool threads in alternativa.

Per alcuni progetti, potrebbe essere utile disabilitare anche il parallelismo per migliorare i tempi di avvio. Per farlo, utilizzare il flag --no-file-parallelism nella CLI o impostare 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 più adatto per risolvere problemi di compatibilità (come processi in stallo e segfaults), potrebbe risultare leggermente più lento rispetto a pool: 'threads' in progetti di grandi dimensioni.

È possibile tentare di 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 è un metodo per suddividere la suite di test in gruppi, o shard. Questo è particolarmente utile quando si dispone di una suite di test estesa e di più macchine in grado di eseguire contemporaneamente sottoinsiemi di essa.

Per distribuire i test di Vitest su più esecuzioni, utilizzare l'opzione --shard insieme all'opzione --reporter=blob:

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

Vitest divide i file di test, non i singoli casi di test, in shard. Se si hanno 1000 file di test, l'opzione --shard=1/4 eseguirà 250 file di test, indipendentemente dal numero di casi di test contenuti in ciascun file.

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

vitest run --merge-reports

Esempio di azione Github

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

# Ispirato da 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

Lo sharding dei test può essere vantaggioso anche su macchine con un elevato numero di core CPU.

Vitest eseguirà un solo server Vite nel thread principale. I restanti thread vengono utilizzati per eseguire i file di test. Su una macchina con un elevato numero di core CPU, il thread principale può diventare un collo di bottiglia, non riuscendo a gestire tutte le richieste provenienti dagli altri thread. Ad esempio, su una macchina con 32 CPU, il thread principale è responsabile della gestione del carico generato dai 31 thread di test.

Per ridurre il carico sul server Vite del thread principale, è possibile utilizzare lo sharding dei test. Il carico può essere bilanciato tra più server Vite.

# Esempio per dividere i test su una macchina con 32 CPU in 4 shard.
# Dato che ogni processo richiede 1 thread principale, ci sono 7 thread disponibili per i runner di test (1+7)*4 = 32
# Usa VITEST_MAX_THREADS o VITEST_MAX_FORKS a seconda del pool utilizzato:
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