Poprawa wydajności

Izolacja testów

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

• pula threads uruchamia każdy plik testowy w osobnym Workerze.
• pula forks uruchamia każdy plik testowy w odrębnym procesie potomnym.
• pula vmThreads uruchamia każdy plik testowy w osobnym kontekście VM, ale wykorzystuje workery do przetwarzania równoległego.

Izolacja testów może znacząco wydłużyć czas ich wykonywania, co bywa niepożądane w projektach, które nie opierają się na efektach ubocznych i prawidłowo zarządzają swoim stanem (co jest typowe dla projektów w środowisku node). W takich przypadkach wyłączenie izolacji poprawi szybkość testów. Można to zrobić, podając flagę --no-isolate w CLI lub ustawiając opcję test.isolate w konfiguracji na false. Jeśli używasz kilku pul jednocześnie z poolMatchGlobs, możesz również wyłączyć izolację dla konkretnej puli.

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, aby poprawić wydajność testów, rozważ użycie puli threads.

W niektórych projektach korzystne może być również wyłączenie równoległości w celu poprawy czasu uruchamiania. Aby to zrobić, podaj flagę --no-file-parallelism w 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' jest bardziej odporna na problemy ze zgodnością (takie jak zawieszony proces i błędy segmentacji), może być nieco wolniejsza niż pool: 'threads' w większych projektach.

Możesz spróbować poprawić 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

Dzielenie testów (sharding) polega na jednoczesnym uruchamianiu małych podzbiorów przypadków testowych. Może to być przydatne, gdy dysponujesz wieloma maszynami, które mogą być wykorzystane do równoległego uruchamiania testów.

Aby podzielić testy Vitest na wiele różnych uruchomień, użyj opcji --shard wraz 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

Zbierz wyniki przechowywane w katalogu .vitest-reports z każdej z maszyn i połącz je za pomocą opcji --merge-reports:

vitest --merge-reports

Przykład akcji GitHub

Ta konfiguracja jest również wykorzystywana 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@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

Sharding testów może być również przydatny na maszynach z dużą liczbą rdzeni CPU.

Vitest uruchamia tylko jeden serwer Vite w wątku głównym. Pozostałe wątki są używane do uruchamiania plików testowych. Na maszynie z dużą liczbą rdzeni CPU główny wątek może stać się wąskim gardłem wydajności, ponieważ nie jest w stanie obsłużyć wszystkich żądań pochodzących od wątków testowych. Na przykład na maszynie z 32 rdzeniami CPU główny wątek jest odpowiedzialny za obsługę obciążenia pochodzącego z 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 między wiele serwerów Vite.

# Przykład podziału testów na 32 CPU na 4 shardy.
# Ponieważ każdy proces potrzebuje 1 wątku głównego, 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 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 --merge-reports