Analyse des performances des tests

Lorsque vous exécutez Vitest, il fournit plusieurs métriques de temps pour vos tests :

RUN  v2.1.1 /x/vitest/examples/profiling

✓ test/prime-number.test.ts (1) 4517ms
  ✓ generate prime number 4517ms

Test Files  1 passed (1)
     Tests  1 passed (1)
  Start at  09:32:53
  Duration  4.80s (transform 44ms, setup 0ms, collect 35ms, tests 4.52s, environment 0ms, prepare 81ms)
  # Time metrics ^^

• Transform : Temps total consacré à la transformation des fichiers. Voir Transformation de fichiers.
• Setup : Temps consacré à l'exécution des fichiers setupFiles.
• Collect : Temps nécessaire pour collecter tous les tests dans les fichiers de test. Cela inclut le temps d'importation de toutes les dépendances de fichiers.
• Tests : Temps consacré à l'exécution des cas de test.
• Environment : Temps consacré à la configuration de l'environment de test, par exemple JSDOM.
• Prepare : Temps utilisé par Vitest pour préparer le lanceur de tests.

Lanceur de tests

Si le temps d'exécution de vos tests est élevé, vous pouvez générer un profil du lanceur de tests. Pour les options suivantes, consultez la documentation de NodeJS :

• --cpu-prof
• --heap-prof
• --prof

WARNING

L'option --prof ne fonctionne pas avec pool: 'threads' en raison des limitations de node:worker_threads.

Pour transmettre ces options au lanceur de tests de Vitest, définissez poolOptions.<pool>.execArgv dans votre configuration Vitest :

Forks

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    pool: 'forks',
    poolOptions: {
      forks: {
        execArgv: [
          '--cpu-prof',
          '--cpu-prof-dir=test-runner-profile',
          '--heap-prof',
          '--heap-prof-dir=test-runner-profile',
        ],

        // Pour générer un seul profil
        singleFork: true,
      },
    },
  },
});

Threads

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    pool: 'threads',
    poolOptions: {
      threads: {
        execArgv: [
          '--cpu-prof',
          '--cpu-prof-dir=test-runner-profile',
          '--heap-prof',
          '--heap-prof-dir=test-runner-profile',
        ],

        // Pour générer un seul profil
        singleThread: true,
      },
    },
  },
});

Une fois les tests exécutés, des fichiers test-runner-profile/*.cpuprofile et test-runner-profile/*.heapprofile devraient être générés. Consultez Inspection des enregistrements de profilage pour savoir comment analyser ces fichiers.

Pour un exemple, consultez Profiling | Examples.

Thread principal

Le profilage du thread principal est utile pour déboguer l'utilisation de Vite par Vitest ainsi que les fichiers globalSetup. C'est également l'endroit où vos plugins Vite s'exécutent.

TIP

Consultez Performance | Vite pour plus de conseils sur le profilage spécifique à Vite.

Nous recommandons vite-plugin-inspect pour profiler les performances de votre plugin Vite.

Pour ce faire, vous devrez transmettre des arguments au processus Node exécutant Vitest.

$ node --cpu-prof --cpu-prof-dir=main-profile ./node_modules/vitest/vitest.mjs --run
#      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                                  ^^^^^
#               Arguments NodeJS                                           Arguments Vitest

Une fois les tests exécutés, un fichier main-profile/*.cpuprofile devrait être généré. Consultez Inspection des enregistrements de profilage pour savoir comment analyser ces fichiers.

Transformation de fichiers

Si le temps de transformation et de collecte de vos tests est élevé, vous pouvez utiliser la variable d'environnement DEBUG=vite-node:* pour voir quels fichiers sont transformés et exécutés par vite-node.

$ DEBUG=vite-node:* vitest --run

 RUN  v2.1.1 /x/vitest/examples/profiling

  vite-node:server:request /x/vitest/examples/profiling/global-setup.ts +0ms
  vite-node:client:execute /x/vitest/examples/profiling/global-setup.ts +0ms
  vite-node:server:request /x/vitest/examples/profiling/test/prime-number.test.ts +45ms
  vite-node:client:execute /x/vitest/examples/profiling/test/prime-number.test.ts +26ms
  vite-node:server:request /src/prime-number.ts +9ms
  vite-node:client:execute /x/vitest/examples/profiling/src/prime-number.ts +9ms
  vite-node:server:request /src/unnecessary-file.ts +6ms
  vite-node:client:execute /x/vitest/examples/profiling/src/unnecessary-file.ts +4ms
...

Cette stratégie de profilage est un excellent moyen d'identifier les transformations inutiles causées par les fichiers "barrel". Si ces journaux contiennent des fichiers qui ne devraient pas être chargés lors de l'exécution de votre test, cela pourrait indiquer que vous avez des fichiers "barrel" qui importent des fichiers inutilement.

Vous pouvez également utiliser Vitest UI pour déboguer les ralentissements causés par les fichiers "barrel". L'exemple ci-dessous montre comment l'importation de fichiers sans utiliser de fichier "barrel" réduit le nombre de fichiers transformés d'environ 85 %.

File tree

├── src
│   └── utils
│       ├── currency.ts
│       ├── formatters.ts  <-- Fichier à tester
│       ├── index.ts
│       ├── location.ts
│       ├── math.ts
│       ├── time.ts
│       └── users.ts
├── test
│   └── formatters.test.ts
└── vitest.config.ts

example.test.ts

import { expect, test } from 'vitest';
import { formatter } from '../src/utils'; 
import { formatter } from '../src/utils/formatters'; 

test('formatter works', () => {
  expect(formatter).not.toThrow();
});

Pour voir comment les fichiers sont transformés, vous pouvez utiliser la variable d'environnement VITE_NODE_DEBUG_DUMP afin d'écrire les fichiers transformés sur le système de fichiers :

$ VITE_NODE_DEBUG_DUMP=true vitest --run

[vite-node] [debug] dump modules to /x/examples/profiling/.vite-node/dump

 RUN  v2.1.1 /x/vitest/examples/profiling
...

$ ls .vite-node/dump/
_x_examples_profiling_global-setup_ts-1292904907.js
_x_examples_profiling_test_prime-number_test_ts-1413378098.js
_src_prime-number_ts-525172412.js

Couverture de code

Si la génération de la couverture de code est lente pour votre projet, vous pouvez utiliser la variable d'environnement DEBUG=vitest:coverage pour activer la journalisation des performances.

$ DEBUG=vitest:coverage vitest --run --coverage

 RUN  v3.1.1 /x/vitest-example

  vitest:coverage Reading coverage results 2/2
  vitest:coverage Converting 1/2
  vitest:coverage 4 ms /x/src/multiply.ts
  vitest:coverage Converting 2/2
  vitest:coverage 552 ms /x/src/add.ts
  vitest:coverage Uncovered files 1/2
  vitest:coverage File "/x/src/large-file.ts" is taking longer than 3s
  vitest:coverage 3027 ms /x/src/large-file.ts
  vitest:coverage Uncovered files 2/2
  vitest:coverage 4 ms /x/src/untested-file.ts
  vitest:coverage Generate coverage total time 3521 ms

Cette approche de profilage est excellente pour détecter les fichiers volumineux qui sont accidentellement pris en compte par les fournisseurs de couverture. Par exemple, si votre configuration inclut accidentellement de gros fichiers Javascript minifiés dans la couverture de code, ceux-ci devraient apparaître dans les journaux. Dans ces cas, il pourrait être judicieux d'ajuster vos options coverage.include et coverage.exclude.

Inspection des enregistrements de profilage

Vous pouvez inspecter le contenu des fichiers *.cpuprofile et *.heapprofile à l'aide de divers outils. Consultez la liste ci-dessous pour des exemples.

• Speedscope
• Performance Profiling JavaScript in Visual Studio Code
• Profile Node.js performance with the Performance panel | developer.chrome.com
• Memory panel overview | developer.chrome.com