Amélioration des performances

Isolation des tests

Par défaut, Vitest exécute chaque fichier de test dans un environnement isolé, basé sur le pool configuré :

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

Cette isolation peut considérablement augmenter la durée des tests, ce qui n'est pas toujours souhaitable pour les projets qui ne dépendent pas d'effets secondaires et gèrent correctement leur état (ce qui est généralement le cas pour les projets utilisant un environnement node). Dans de telles situations, désactiver l'isolation peut améliorer la vitesse de vos tests. Pour ce faire, vous pouvez passer l'option --no-isolate à la CLI ou définir la propriété test.isolate à false dans votre configuration. Si vous utilisez plusieurs pools simultanément avec poolMatchGlobs, vous avez également la possibilité de désactiver l'isolation pour un pool spécifique.

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 certains pools
    poolOptions: {
      forks: {
        isolate: false,
      },
    },
  },
});

TIP

Si vous utilisez le pool vmThreads, la désactivation de l'isolation n'est pas possible. 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 démarrage. Pour ce faire, passez l'option --no-file-parallelism à la CLI ou définissez la propriété test.fileParallelism à false dans votre 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 dans le pool: 'forks'. Bien que le pool 'forks' soit plus adapté pour résoudre les problèmes de compatibilité (tels que les processus bloqués et les erreurs de segmentation), il peut être légèrement plus lent que pool: 'threads' dans les projets de grande envergure.

Vous pouvez tenter d'améliorer le temps d'exécution de vos tests en modifiant l'option pool dans votre 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 à exécuter un petit sous-ensemble de cas de test à la fois. Cette approche est particulièrement utile si vous disposez de plusieurs machines pouvant être utilisées pour exécuter des tests simultanément.

Pour diviser les tests Vitest en 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

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

vitest --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@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

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

Vitest n'exécute qu'un seul serveur Vite dans son thread principal. Les autres threads sont utilisés pour exécuter les fichiers de test. Sur une machine avec un nombre élevé de CPU, le thread principal peut devenir un goulot d'étranglement car il ne peut pas gérer toutes les requêtes provenant des threads. Par exemple, sur une machine à 32 CPU, le thread principal doit gérer la charge provenant de 31 threads de test.

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

# Exemple de division des tests sur 32 CPU en 4 shards.
# Chaque processus nécessitant un thread principal, il y a 7 threads pour les lanceurs 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 --merge-reports