Teljesítmény javítása

Teszt izoláció

Alapértelmezés szerint a Vitest minden tesztfájlt egy izolált környezetben futtat, a pool beállítástól függően:

• A threads pool minden tesztfájlt külön Worker szálban futtat.
• A forks pool minden tesztfájlt külön forkolt gyermekfolyamatban futtat.
• A vmThreads pool minden tesztfájlt külön VM kontextusban futtat, de a párhuzamosság érdekében munkafolyamatokat használ.

Ez jelentősen megnövelheti a tesztidőt, ami nem kívánatos olyan projektek esetében, amelyek nem támaszkodnak mellékhatásokra és megfelelően kezelik az állapotukat (ami általában igaz a Node.js környezetű projektekre). Ebben az esetben az izoláció kikapcsolása növelheti a tesztek sebességét. Ehhez átadhatja a --no-isolate flaget a CLI-nek, vagy beállíthatja a konfigurációban a test.isolate tulajdonságot false értékre.

CLI

vitest --no-isolate

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    isolate: false,
    // Az izolációt bizonyos pooloknál is kikapcsolhatja
    poolOptions: {
      forks: {
        isolate: false,
      },
    },
  },
});

TIP

Ha a vmThreads poolt használja, nem kapcsolhatja ki az izolációt. Használja helyette a threads poolt a tesztek teljesítményének javításához.

Néhány projekt esetében célszerű lehet a párhuzamosság kikapcsolása is az indítási idő javítása érdekében. Ehhez adja meg a --no-file-parallelism flaget a CLI-nek, vagy állítsa be a test.fileParallelism tulajdonságot a konfigurációban false értékre.

CLI

vitest --no-file-parallelism

vitest.config.js

import { defineConfig } from 'vitest/config';

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

Pool

Alapértelmezés szerint a Vitest a teszteket a pool: 'forks' beállítással futtatja. Bár a 'forks' pool jobb a kompatibilitási problémák (például függő folyamatok és szegmentálási hibák) kezelésének tekintetében, nagyobb projektekben kissé lassabb lehet, mint a pool: 'threads'.

Megpróbálhatja javítani a tesztfuttatási idejét a pool opció konfigurációban való átállításával:

CLI

vitest --pool=threads

vitest.config.js

import { defineConfig } from 'vitest/config';

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

Sharding

A teszt sharding a tesztcsomag csoportokra, azaz shardokra bontásának folyamata. Ez akkor lehet hasznos, ha nagy tesztcsomaggal és több géppel rendelkezik, amelyek egyszerre futtathatják a csomag részeit.

A Vitest tesztek több futtatás közötti felosztásához használja a --shard opciót a --reporter=blob opcióval együtt:

vitest run --reporter=blob --shard=1/3 # 1. gép
vitest run --reporter=blob --shard=2/3 # 2. gép
vitest run --reporter=blob --shard=3/3 # 3. gép

A Vitest a tesztfájlokat, nem a teszteseteket osztja shardokra. Ha 1000 tesztfájlja van, a --shard=1/4 opció 250 tesztfájlt fog futtatni, függetlenül attól, hogy az egyes fájlok hány tesztesetet tartalmaznak.

Gyűjtse össze az egyes gépekről a .vitest-reports könyvtárban tárolt eredményeket, és egyesítse azokat a --merge-reports opcióval:

vitest run --merge-reports

Github action example

Ezt a beállítást a https://github.com/vitest-tests/test-sharding oldalon is alkalmazzák.

# Inspired from 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

A teszt sharding nagy processzorteljesítményű gépeken is hasznos lehet.

A Vitest csak egyetlen Vite szervert futtat a fő szálon. A többi szál a tesztfájlok futtatására használatos. Nagy processzorteljesítményű gépen a fő szál szűk keresztmetszetté válhat, mivel nem tudja feldolgozni a szálakból érkező összes kérést. Például egy 32 CPU-s gépen a fő szál felelős a 31 teszt szálból érkező terhelés kezeléséért.

A fő szál Vite szerverének terhelésének csökkentéséhez használhatja a teszt shardingot. A terhelés több Vite szerverre is elosztható.

# Példa a tesztek felosztására 32 CPU-n 4 shardra.
# Mivel minden folyamatnak szüksége van 1 fő szálra, 7 szál marad a tesztfuttatók számára (1+7)*4 = 32
# Használja a VITEST_MAX_THREADS vagy VITEST_MAX_FORKS változót a pooltól függően:
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