Amélioration des performances

Isolation des tests

Par défaut, Vitest exécute chaque fichier de test dans un environnement isolé, en fonction du pool configuré :

• Le pool threads exécute chaque fichier de test dans un Worker séparé.
• Le pool forks exécute chaque fichier de test dans un processus enfant forké séparé.
• Le pool vmThreads exécute chaque fichier de test dans un contexte VM séparé, tout en utilisant des workers pour le parallélisme.

Cette isolation peut augmenter considérablement la durée des tests, ce qui peut être indésirable pour les projets qui ne dépendent pas d'effets secondaires et qui nettoient correctement leur état (ce qui est généralement le cas pour les projets utilisant un environnement node). Dans ce cas, la désactivation de l'isolation améliorera la performance de vos tests. Pour ce faire, vous pouvez passer l'option --no-isolate à la CLI ou définir la propriété test.isolate sur false dans la configuration.

CLI

vitest --no-isolate

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    isolate: false,
    // vous pouvez également désactiver l'isolation uniquement pour des pools spécifiques
    poolOptions: {
      forks: {
        isolate: false,
      },
    },
  },
});

TIP

Si vous utilisez le pool vmThreads, vous ne pouvez pas désactiver l'isolation. Pour améliorer les performances de vos tests, envisagez d'utiliser le pool threads à la place.

Pour certains projets, il peut également être souhaitable de désactiver le parallélisme afin d'améliorer le temps de lancement. Pour ce faire, passez l'option --no-file-parallelism à la CLI ou définissez la propriété test.fileParallelism sur false dans la configuration.

CLI

vitest --no-file-parallelism

vitest.config.js

import { defineConfig } from 'vitest/config';

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

Pool

Par défaut, Vitest exécute les tests avec pool: 'forks'. Bien que le pool 'forks' gère mieux les problèmes de compatibilité (processus bloqué et erreurs de segmentation), il peut être légèrement plus lent que pool: 'threads' dans les projets de plus grande envergure.

Vous pouvez essayer d'améliorer le temps d'exécution des tests en modifiant l'option pool dans la configuration :

CLI

vitest --pool=threads

vitest.config.js

import { defineConfig } from 'vitest/config';

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

Sharding

Le sharding de tests consiste à diviser votre suite de tests en groupes, ou « shards ». Cela peut être utile lorsque vous disposez d'une suite de tests volumineuse et de plusieurs machines capables d'exécuter simultanément des sous-ensembles de cette suite.

Pour répartir les tests Vitest sur plusieurs exécutions distinctes, utilisez l'option --shard conjointement avec l'option --reporter=blob :

vitest run --reporter=blob --shard=1/3 # 1ère machine
vitest run --reporter=blob --shard=2/3 # 2ème machine
vitest run --reporter=blob --shard=3/3 # 3ème machine

Vitest divise vos fichiers de test, et non vos cas de test, en shards. Si vous avez 1000 fichiers de test, l'option --shard=1/4 exécutera 250 fichiers de tests, quel que soit le nombre de cas de test que contiennent les fichiers individuels.

Collectez les résultats stockés dans le répertoire .vitest-reports de chaque machine et fusionnez-les à l'aide de l'option --merge-reports :

vitest run --merge-reports

Exemple d'action Github

Cette configuration est également utilisée sur https://github.com/vitest-tests/test-sharding.

# Inspiré de 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

Le sharding de tests peut également s'avérer utile sur les machines dotées d'un nombre élevé de cœurs de CPU.

Vitest n'exécutera qu'un seul serveur Vite sur son thread principal. Les autres threads sont utilisés pour exécuter les fichiers de test. Sur une machine dotée d'un grand nombre de cœurs de CPU, le thread principal peut devenir un point de congestion car il ne peut pas gérer toutes les requêtes provenant des autres threads. Par exemple, sur une machine à 32 cœurs de CPU, le thread principal est responsable de la gestion de la charge provenant des 31 threads de test.

Pour réduire la charge sur le thread principal du serveur Vite, vous pouvez utiliser le sharding de tests. La charge peut être répartie sur plusieurs serveurs Vite.

# Exemple de répartition des tests sur 32 CPU en 4 shards.
# Étant donné que chaque processus nécessite 1 thread principal, 7 threads sont disponibles pour les exécuteurs de tests (1+7)*4 = 32
# Utilisez VITEST_MAX_THREADS ou VITEST_MAX_FORKS selon le pool :
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