Poprawa wydajności

Izolacja testów

Domyślnie Vitest uruchamia każdy plik testowy w izolowanym środowisku, bazując na puli:

• pula threads uruchamia każdy plik testowy w osobnym Workerze
• pula forks uruchamia każdy plik testowy w osobnym procesie potomnym z rozgałęzieniem
• pula vmThreads uruchamia każdy plik testowy w osobnym kontekście VM, ale wykorzystuje procesy robocze do zapewnienia równoległości

Izolacja testów może znacząco wydłużyć czas wykonywania testów. Może to być niepożądane w projektach, które nie polegają na efektach ubocznych i prawidłowo oczyszczają swój stan (co zazwyczaj dotyczy projektów w środowisku node). W takim przypadku wyłączenie izolacji przyspieszy testy. Aby to zrobić, możesz przekazać flagę --no-isolate do CLI lub ustawić właściwość test.isolate w konfiguracji na false.

CLI

vitest --no-isolate

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    isolate: false,
    // możesz również wyłączyć izolację tylko dla konkretnych pul
    poolOptions: {
      forks: {
        isolate: false,
      },
    },
  },
});

TIP

Jeśli używasz puli vmThreads, nie możesz wyłączyć izolacji. Zamiast tego użyj puli threads, aby poprawić wydajność swoich testów.

Dla niektórych projektów może być również pożądane wyłączenie równoległości w celu poprawy czasu uruchamiania testów. Aby to zrobić, podaj flagę --no-file-parallelism do CLI lub ustaw właściwość test.fileParallelism w konfiguracji na false.

CLI

vitest --no-file-parallelism

vitest.config.js

import { defineConfig } from 'vitest/config';

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

Pula

Domyślnie Vitest uruchamia testy w pool: 'forks'. Chociaż pula 'forks' lepiej radzi sobie z problemami kompatybilności (zawieszanie się procesów i błędy segmentacji pamięci), może być nieco wolniejsza niż pool: 'threads' w większych projektach.

Możesz spróbować skrócić czas wykonywania testów, zmieniając opcję pool w konfiguracji:

CLI

vitest --pool=threads

vitest.config.js

import { defineConfig } from 'vitest/config';

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

Sharding

Sharding testów to proces dzielenia zestawu testów na grupy, zwane shardami. Może to być przydatne, gdy masz duży zestaw testów i wiele maszyn, które mogą równocześnie uruchamiać podzbiory tego zestawu.

Aby podzielić testy Vitest na wiele oddzielnych uruchomień, użyj opcji --shard z opcją --reporter=blob:

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

Vitest dzieli pliki testowe na shardy, a nie przypadki testowe. Jeśli masz 1000 plików testowych, opcja --shard=1/4 uruchomi 250 plików testowych, niezależnie od liczby przypadków testowych w poszczególnych plikach.

Zbierz wyniki przechowywane w katalogu .vitest-reports z każdej maszyny i scal je, używając opcji --merge-reports:

vitest run --merge-reports

Przykład akcji Github

Ta konfiguracja jest również używana na https://github.com/vitest-tests/test-sharding.

# Zainspirowane przez 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

Sharding testów może być również przydatny na maszynach z wieloma rdzeniami procesora.

Vitest uruchomi tylko jeden serwer Vite w głównym wątku. Pozostałe wątki są wykorzystywane do uruchamiania plików testowych. Na maszynie wielordzeniowej główny wątek może stać się wąskim gardłem (bottleneck), ponieważ nie jest w stanie obsłużyć wszystkich żądań z wątków testowych. Na przykład na maszynie z 32 rdzeniami CPU główny wątek jest odpowiedzialny za obsługę obciążenia od 31 wątków testowych.

Aby zmniejszyć obciążenie serwera Vite w głównym wątku, możesz użyć shardingu testów. Obciążenie może być rozłożone pomiędzy wiele serwerów Vite.

# Przykład podziału testów na 32 CPU na 4 shardy.
# Ponieważ każdy proces wymaga 1 głównego wątku, dostępnych jest 7 wątków dla wykonawców testów (1+7)*4 = 32
# Użyj VITEST_MAX_THREADS lub VITEST_MAX_FORKS w zależności od wybranej puli:
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