Leistung verbessern

Test-Isolierung

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

• Der threads-Pool führt jede Testdatei in einem separaten Worker aus.
• Der forks-Pool führt jede Testdatei in einem separaten abgespaltenen Kindprozess aus.
• Der vmThreads-Pool führt jede Testdatei in einem separaten VM-Kontext aus, verwendet jedoch Worker für die Parallelität.

Diese Isolierung kann die Testdauer erheblich verlängern. Für Projekte, die keine Nebeneffekte erzeugen und ihren Zustand sauber 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 Isolierung die Testleistung verbessern. Dies erreichen Sie, indem Sie das Flag --no-isolate an die CLI übergeben oder die Eigenschaft test.isolate in der Konfiguration auf false setzen.

CLI

vitest --no-isolate

vitest.config.js

import { defineConfig } from 'vitest/config';

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

TIP

Wenn Sie den vmThreads-Pool verwenden, kann die Isolierung nicht deaktiviert werden. Um die Testleistung zu verbessern, sollten Sie stattdessen den threads-Pool in Betracht ziehen.

Für einige Projekte kann es auch vorteilhaft sein, die Parallelität zu deaktivieren, um die Startzeit der Tests zu verkürzen. Dazu übergeben Sie das Flag --no-file-parallelism an die CLI 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 führt Vitest Tests im pool: 'forks' aus. Obwohl der 'forks'-Pool eine bessere Kompatibilität bei Problemen wie hängengebliebenen Prozessen und Segmentierungsfehlern bietet, kann er in größeren Projekten etwas langsamer sein als pool: 'threads'.

Sie können versuchen, die Testlaufzeit zu 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 ist ein Prozess, bei dem Ihre Test-Suite in mehrere Gruppen oder Shards aufgeteilt wird. Dies ist besonders nützlich, wenn Sie eine große Test-Suite und mehrere Maschinen zur Verfügung haben, die Teile dieser Suite gleichzeitig ausführen können.

Um Vitest-Tests auf mehrere separate Läufe aufzuteilen, verwenden Sie die Option --shard in Verbindung 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

Vitest teilt Ihre Testdateien, nicht Ihre Testfälle, in Shards auf. Wenn Sie 1000 Testdateien haben, führt die Option --shard=1/4 250 Testdateien aus, unabhängig davon, wie viele Testfälle einzelne Dateien enthalten.

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

vitest run --merge-reports

Github action example

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

Test-Sharding kann auch auf Maschinen mit einer hohen Anzahl an CPUs vorteilhaft sein.

Vitest führt nur einen einzigen Vite-Server in seinem Hauptthread aus. Die restlichen Threads werden für die Ausführung von Testdateien verwendet. Auf einer Maschine mit vielen CPUs kann der Hauptthread zu einem Engpass werden, da er möglicherweise nicht alle Anfragen der Test-Threads effizient verarbeiten kann. Zum Beispiel ist auf einer 32-CPU-Maschine der Hauptthread dafür verantwortlich, die Last von 31 Test-Threads zu bewältigen.

Um die Last des Vite-Servers im Hauptthread zu reduzieren, können Sie Test-Sharding verwenden. Die Last kann so auf mehrere Vite-Server verteilt werden.

# Beispiel für die Aufteilung von Tests auf 32 CPUs in 4 Shards.
# Da jeder Prozess 1 Hauptthread benötigt, gibt es 7 Threads für Testrunner (1+7)*4 = 32
# Verwenden Sie VITEST_MAX_THREADS oder VITEST_MAX_FORKS je nach 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