Leistungsoptimierung

Testisolation

Vitest führt standardmäßig jede Testdatei in einer isolierten Umgebung aus, basierend auf dem Pool:

• Der threads-Pool nutzt für jede Testdatei einen separaten Worker.
• Der forks-Pool nutzt für jede Testdatei einen separaten abgespalteten Child-Prozess.
• Der vmThreads-Pool nutzt für jede Testdatei einen separaten VM-Kontext, verwendet jedoch Worker für die Parallelisierung.

Diese Isolation kann die Testdauer erheblich verlängern. Für Projekte, die keine unerwünschten Nebeneffekte erzeugen und ihren Zustand ordnungsgemäß bereinigen (was typischerweise auf Projekte in einer node-Umgebung zutrifft), ist dies möglicherweise nicht wünschenswert. In solchen Fällen kann das Deaktivieren der Isolation die Testleistung verbessern. Dazu können Sie das Flag --no-isolate in der CLI angeben oder die Eigenschaft test.isolate in der Konfiguration auf false setzen. Wenn Sie mehrere Pools gleichzeitig mit poolMatchGlobs verwenden, können Sie die Isolation auch gezielt für einen bestimmten Pool deaktivieren.

CLI

vitest --no-isolate

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    isolate: false,
    // Sie können die Isolation auch nur für bestimmte Pools deaktivieren
    poolOptions: {
      forks: {
        isolate: false,
      },
    },
  },
});

TIP

Wenn Sie den vmThreads-Pool verwenden, kann die Isolation nicht deaktiviert werden. Um die Testleistung zu verbessern, sollten Sie stattdessen den threads-Pool nutzen.

Bei einigen Projekten kann es auch sinnvoll sein, die Parallelität zu deaktivieren, um die Startzeit der Tests zu verbessern. Dazu geben Sie das Flag --no-file-parallelism in der CLI an oder setzen die Eigenschaft test.fileParallelism in der Konfiguration auf false.

CLI

vitest --no-file-parallelism

vitest.config.js

import { defineConfig } from 'vitest/config';

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

Pool

Standardmäßig verwendet Vitest den 'forks'-Pool für Tests. Obwohl der 'forks'-Pool bei Kompatibilitätsproblemen (wie hängenden Prozessen und Speicherzugriffsfehlern) vorteilhafter ist, kann er in größeren Projekten etwas langsamer sein als der 'threads'-Pool.

Sie können die Testlaufzeit verbessern, indem Sie die pool-Option in der Konfiguration ändern:

CLI

vitest --pool=threads

vitest.config.js

import { defineConfig } from 'vitest/config';

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

Sharding

Test-Sharding bedeutet die gleichzeitige Ausführung einer Teilmenge von Testfällen. Dies kann nützlich sein, wenn Sie Tests parallel auf mehreren Maschinen ausführen möchten.

Um Vitest-Tests auf mehrere separate Läufe aufzuteilen, verwenden Sie die Option --shard zusammen mit der Option --reporter=blob:

vitest run --reporter=blob --shard=1/3 # 1. Maschine
vitest run --reporter=blob --shard=2/3 # 2. Maschine
vitest run --reporter=blob --shard=3/3 # 3. Maschine

Sammeln Sie die im .vitest-reports-Verzeichnis gespeicherten Ergebnisse von jeder Maschine und führen Sie sie mit der Option --merge-reports zusammen:

vitest --merge-reports

Beispiel für eine GitHub Action

Dieses Setup wird auch unter https://github.com/vitest-tests/test-sharding verwendet.

# Inspiriert von 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

Test-Sharding kann auch auf Maschinen mit vielen CPUs nützlich sein.

Vitest betreibt nur einen einzigen Vite-Server in seinem Haupt-Thread. Die übrigen Threads dienen der Ausführung von Testdateien. Auf einer Maschine mit vielen CPUs kann der Haupt-Thread zum Flaschenhals werden, da er möglicherweise nicht alle Anfragen der Test-Threads effizient verarbeiten kann. Zum Beispiel ist auf einer Maschine mit 32 CPUs der Haupt-Thread dafür verantwortlich, die Last von 31 Test-Threads zu bewältigen.

Um die Last des Vite-Servers im Haupt-Thread zu reduzieren, können Sie Test-Sharding verwenden. Dies ermöglicht die Verteilung der Last auf mehrere Vite-Server.

# Beispiel für die Aufteilung von Tests auf 32 CPUs in 4 Shards.
# Da jeder Prozess einen Haupt-Thread benötigt, stehen 7 Threads für Test-Runner zur Verfügung (1+7)*4 = 32
# Verwenden Sie VITEST_MAX_THREADS oder VITEST_MAX_FORKS, abhängig vom verwendeten 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