Performansı İyileştirme

Test İzolasyonu

Varsayılan olarak Vitest, her test dosyasını havuza dayalı izole bir ortamda çalıştırır:

• threads havuzu her test dosyasını ayrı bir Worker içinde çalıştırır.
• forks havuzu her test dosyasını ayrı bir çatallanmış alt işlemde çalıştırır.
• vmThreads havuzu her test dosyasını ayrı bir VM bağlamında çalıştırır, ancak paralellik için worker'ları kullanır.

Bu durum, test sürelerini önemli ölçüde uzatabilir. Yan etkilere dayanmayan ve durumlarını düzgün bir şekilde temizleyen projeler (genellikle node ortamına sahip projeler için geçerlidir) için bu istenmeyebilir. Bu gibi durumlarda izolasyonu devre dışı bırakmak testlerinizi hızlandıracaktır. Bunu yapmak için CLI'ye --no-isolate bayrağını ekleyebilir veya yapılandırmadaki test.isolate özelliğini false olarak ayarlayabilirsiniz. poolMatchGlobs ile aynı anda birden fazla havuz kullanıyorsanız, belirli bir havuz için izolasyonu da devre dışı bırakabilirsiniz.

CLI

vitest --no-isolate

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    isolate: false,
    // İzolasyonu sadece belirli havuzlar için de devre dışı bırakabilirsiniz
    poolOptions: {
      forks: {
        isolate: false,
      },
    },
  },
});

TIP

vmThreads havuzunu kullanıyorsanız, izolasyonu devre dışı bırakamazsınız. Testlerinizin performansını artırmak için bunun yerine threads havuzunu kullanın.

Bazı projeler için, başlangıç süresini iyileştirmek amacıyla paralelliği devre dışı bırakmak da istenebilir. Bunu yapmak için CLI'ye --no-file-parallelism bayrağını ekleyin veya yapılandırmadaki test.fileParallelism özelliğini false olarak ayarlayın.

CLI

vitest --no-file-parallelism

vitest.config.js

import { defineConfig } from 'vitest/config';

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

Havuz

Varsayılan olarak Vitest, testleri pool: 'forks' havuzunda çalıştırır. 'forks' havuzu uyumluluk sorunları (donan süreç ve segfault'lar) için daha iyi olsa da, daha büyük projelerde pool: 'threads''ten biraz daha yavaş olabilir.

Yapılandırmadaki pool seçeneğini değiştirerek test çalışma süresini iyileştirmeyi deneyebilirsiniz:

CLI

vitest --pool=threads

vitest.config.js

import { defineConfig } from 'vitest/config';

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

Parçalama

Test parçalama, bir seferde test senaryolarının küçük bir alt kümesini çalıştırmak anlamına gelir. Testleri eş zamanlı olarak çalıştırmak için kullanılabilecek birden fazla makineniz varsa faydalı olabilir.

Vitest testlerini birden fazla farklı çalıştırmaya bölmek için --shard seçeneğini --reporter=blob seçeneğiyle birlikte kullanın:

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

Her makineden .vitest-reports dizininde kaydedilen sonuçları toplayın ve bunları --merge-reports seçeneğiyle birleştirin:

vitest --merge-reports

Github Actions örneği

Bu yapılandırma aynı zamanda https://github.com/vitest-tests/test-sharding adresinde de kullanılmaktadır.

# https://playwright.dev/docs/test-sharding adresinden esinlenilmiştir
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

Test parçalama, yüksek CPU'lu makinelerde de yararlı olabilir.

Vitest, ana iş parçacığında yalnızca tek bir Vite sunucusu çalıştıracaktır. Kalan iş parçacıkları test dosyalarını çalıştırmak için kullanılır. Yüksek CPU'lu bir makinede, ana iş parçacığı, iş parçacıklarından gelen tüm istekleri kaldıramadığı için bir darboğaz haline gelebilir. Örneğin, 32 CPU'lu bir makinede ana iş parçacığı, 31 test iş parçacığından gelen yükü yönetmekle sorumludur.

Ana iş parçacığının Vite sunucusundan gelen yükü azaltmak için test parçalama kullanabilirsiniz. Yük, birden fazla Vite sunucusu arasında dengelenebilir.

# 32 CPU'daki testleri 4 parçaya bölme örneği.
# Her işlem 1 ana iş parçacığına ihtiyaç duyduğundan, test çalıştırıcıları için 7 iş parçacığı kalır (1+7)*4 = 32
# Havuz türüne bağlı olarak VITEST_MAX_THREADS veya VITEST_MAX_FORKS kullanın:
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