Zlepšení výkonu

Izolace testů

Vitest ve výchozím nastavení spouští každý testovací soubor v izolovaném prostředí, které je založeno na poolu:

• pool threads spouští každý testovací soubor v samostatném Workeru
• pool forks spouští každý testovací soubor v samostatném forkovaném podřízeném procesu
• pool vmThreads spouští každý testovací soubor v samostatném VM kontextu, ale pro paralelismus využívá workery

Tato izolace může výrazně prodloužit dobu běhu testů, což nemusí být žádoucí pro projekty, které se nespoléhají na vedlejší efekty a správně čistí svůj stav (což je obvykle případ projektů v prostředí node). V takovém případě deaktivace izolace zlepší rychlost vašich testů. K tomu můžete použít přepínač --no-isolate v příkazovém řádku (CLI) nebo nastavit vlastnost test.isolate v konfiguraci na false.

CLI

vitest --no-isolate

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    isolate: false,
    // izolaci můžete zakázat pouze pro konkrétní pooly
    poolOptions: {
      forks: {
        isolate: false,
      },
    },
  },
});

TIP

Pokud používáte pool vmThreads, nemůžete izolaci zakázat. Místo toho zvažte použití poolu threads pro zlepšení výkonu vašich testů.

Pro některé projekty může být také žádoucí zakázat paralelismus pro zlepšení doby spuštění. K tomu použijte přepínač --no-file-parallelism v příkazovém řádku (CLI) nebo nastavte vlastnost test.fileParallelism v konfiguraci na false.

CLI

vitest --no-file-parallelism

vitest.config.js

import { defineConfig } from 'vitest/config';

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

Pool

Vitest ve výchozím nastavení spouští testy v pool: 'forks'. I když je pool 'forks' lepší pro řešení problémů s kompatibilitou (zablokovaný proces a segmentační chyby), může být u větších projektů o něco pomalejší než pool: 'threads'.

Můžete zkusit zlepšit dobu běhu testů přepnutím možnosti pool v konfiguraci:

CLI

vitest --pool=threads

vitest.config.js

import { defineConfig } from 'vitest/config';

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

Sharding

Sharding testů je proces rozdělení vaší testovací sady do skupin, neboli shardů. To může být užitečné, když máte velkou testovací sadu a více strojů, které by mohly spouštět dílčí množiny této sady souběžně.

Pro rozdělení Vitest testů do více běhů použijte možnost --shard s možností --reporter=blob:

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

Vitest rozděluje vaše testovací soubory, nikoli testovací scénáře, do shardů. Pokud máte 1000 testovacích souborů, možnost --shard=1/4 spustí 250 testovacích souborů, bez ohledu na to, kolik testovacích scénářů jednotlivé soubory obsahují.

Shromážděte výsledky uložené v adresáři .vitest-reports z každého běhu a sloučte je pomocí možnosti --merge-reports.

vitest run --merge-reports

Příklad akce GitHub

Toto nastavení se také používá na https://github.com/vitest-tests/test-sharding.

# Inspirováno z 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ů může být užitečný i na strojích s velkým počtem CPU.

Vitest spustí pouze jeden Vite server ve svém hlavním vlákně. Zbytek vláken se používá ke spouštění testovacích souborů. Na stroji s vysokým počtem CPU se hlavní vlákno může stát úzkým místem, protože nemůže zpracovat všechny požadavky přicházející z testovacích vláken. Například na stroji s 32 CPU je hlavní vlákno zodpovědné za zpracování zátěže přicházející z 31 testovacích vláken.

Pro snížení zátěže ze serveru Vite hlavního vlákna můžete použít sharding testů. Zátěž lze vyvážit na více Vite serverů.

# Příklad rozdělení testů na 32 CPU do 4 shardů.
# Jelikož každý proces potřebuje 1 hlavní vlákno, je zde 7 vláken pro testovací procesy (1+7)*4 = 32
# Použijte VITEST_MAX_THREADS nebo VITEST_MAX_FORKS v závislosti na poolu:
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