Pool Personnalisé
Vitest exécute des tests dans des pools. Par défaut, il y a plusieurs pools :
threads
pour exécuter des tests en utilisantnode:worker_threads
(l’isolation est fournie avec un nouveau contexte de travail)forks
pour exécuter des tests en utilisantnode:child_process
(l’isolation est fournie avec un nouveau processuschild_process.fork
)vmThreads
pour exécuter des tests en utilisantnode:worker_threads
(mais l’isolation est fournie avec le modulevm
au lieu d’un nouveau contexte de travail)browser
pour exécuter des tests en utilisant des fournisseurs de navigateurtypescript
pour effectuer une vérification de type sur les tests
Vous pouvez fournir votre propre pool en spécifiant un chemin de fichier :
API
Le fichier spécifié dans l’option pool
doit exporter une fonction (peut être asynchrone) qui accepte l’interface Vitest
comme première option. Cette fonction doit retourner un objet correspondant à l’interface ProcessPool
:
La fonction n’est appelée qu’une seule fois (à moins que la configuration du serveur ne soit mise à jour), et c’est généralement une bonne idée d’initialiser tout ce dont vous avez besoin pour les tests à l’intérieur de cette fonction et de le réutiliser lorsque runTests
est appelé.
Vitest appelle runTest
lorsque de nouveaux tests sont programmés pour s’exécuter. Il ne l’appellera pas si files
est vide. Le premier argument est un tableau de tuples : le premier élément est une référence à un projet de travail et le second est un chemin absolu vers un fichier de test. Les fichiers sont triés à l’aide de sequencer
avant que runTests
ne soit appelé. Il est possible (mais peu probable) d’avoir le même fichier deux fois, mais il aura toujours un projet différent - cela est mis en œuvre via la configuration vitest.workspace.ts
.
Vitest attendra que runTests
soit exécuté avant de terminer un run (c’est-à-dire, il émettra onFinished
uniquement après que runTests
soit résolu).
Si vous utilisez un pool personnalisé, vous devrez fournir les fichiers de test et leurs résultats vous-même - vous pouvez vous référer à vitest.state
pour cela (les plus importants sont collectFiles
et updateTasks
). Vitest utilise la fonction startTests
du package @vitest/runner
pour cela.
Vitest appellera collectTests
si vitest.collect
est appelé ou si vitest list
est invoqué via une commande CLI. Cela fonctionne de la même manière que runTests
, mais vous n’avez pas à exécuter les rappels de test, seulement à rapporter leurs tâches en appelant vitest.state.collectFiles(files)
.
Pour communiquer entre différents processus, vous pouvez créer un objet de méthodes en utilisant createMethodsRPC
de vitest/node
, et utiliser n’importe quelle forme de communication que vous préférez. Par exemple, pour utiliser WebSockets avec birpc
, vous pouvez écrire quelque chose comme ceci :
Pour vous assurer que chaque test est collecté, vous appelleriez ctx.state.collectFiles
et le rapporteriez aux reporters de Vitest :
Vous pouvez voir un exemple simple dans pool/custom-pool.ts.