Améliorer la performance

Isolation des tests

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

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é, mais il utilise des workers pour le parallélisme.

Cela augmente considérablement les temps de test, ce qui peut ne pas être souhaitable pour les projets qui ne dépendent pas des effets de bord et nettoient correctement leur état (ce qui est généralement vrai pour les projets avec un environnement node). Dans ce cas, désactiver l’isolation améliorera la vitesse de vos tests. Pour cela, vous pouvez fournir le drapeau --no-isolate à la CLI ou définir la propriété test.isolate dans la configuration à false. Si vous utilisez plusieurs pools en même temps avec poolMatchGlobs, vous pouvez également désactiver l’isolation pour un pool spécifique que vous utilisez.

CLI
vitest.config.js

vitest --no-isolate

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,
      },
    },
  },
})

Pour certains projets, il peut également être souhaitable de désactiver le parallélisme pour améliorer le temps de démarrage. Pour cela, fournissez le drapeau --no-file-parallelism à la CLI ou définissez la propriété test.fileParallelism dans la configuration à false.

CLI
vitest.config.js

vitest --no-file-parallelism

import { defineConfig } from 'vitest/config'

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

Pool

Par défaut, Vitest exécute des tests dans pool: 'forks'. Bien que le pool 'forks' soit meilleur pour les problèmes de compatibilité (processus en attente et segfaults), il peut être légèrement plus lent que pool: 'threads' dans des projets plus vastes.

Vous pouvez tenter d’améliorer le temps d’exécution des tests en changeant l’option pool dans la configuration :

CLI
vitest.config.js

vitest --pool=threads

import { defineConfig } from 'vitest/config'

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

Sharding

Le sharding des tests signifie exécuter un petit sous-ensemble de cas de test à la fois. Cela peut être utile lorsque vous avez plusieurs machines qui pourraient être utilisées pour exécuter des tests simultanément.

Pour diviser les tests Vitest en plusieurs exécutions différentes, utilisez l’option --shard 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 répertoire .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: Installer pnpm
        uses: pnpm/action-setup@v4

      - name: Installer les dépendances
        run: pnpm i

      - name: Exécuter les tests
        run: pnpm run test --reporter=blob --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }}

      - name: Télécharger le rapport blob dans les artefacts des actions GitHub
        if: ${{ !cancelled() }}
        uses: actions/upload-artifact@v4
        with:
          name: blob-report-${{ matrix.shardIndex }}
          path: .vitest-reports/*
          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: Installer pnpm
        uses: pnpm/action-setup@v4

      - name: Installer les dépendances
        run: pnpm i

      - name: Télécharger les rapports blob des artefacts des actions GitHub
        uses: actions/download-artifact@v4
        with:
          path: .vitest-reports
          pattern: blob-report-*
          merge-multiple: true

      - name: Fusionner les rapports
        run: npx vitest --merge-reports

Le sharding des tests peut également devenir utile sur des machines à haute capacité de CPU.

Vitest exécutera uniquement un serveur Vite dans son thread principal. Le reste des threads est utilisé pour exécuter les fichiers de test. Dans une machine à haute capacité de CPU, le thread principal peut devenir un goulot d’étranglement car il ne peut pas gérer toutes les demandes provenant des threads. Par exemple, dans une machine à 32 CPU, le thread principal est responsable de gérer la charge provenant de 31 threads de test.

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

# Exemple de division des tests sur 32 CPU en 4 shards.
# Comme chaque processus nécessite 1 thread principal, il y a 7 threads pour les runners de test (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