Skip to content
Vitest 2
Main Navigation PrzewodnikAPIKonfiguracjaTryb przeglądarkiZaawansowany
2.1.9
1.6.1
0.34.6

Polski

English
简体中文
繁體中文
Español
Français
Русский
Português – Brasil
Deutsch
日本語
한국어
Italiano
Türkçe
čeština
magyar

Polski

English
简体中文
繁體中文
Español
Français
Русский
Português – Brasil
Deutsch
日本語
한국어
Italiano
Türkçe
čeština
magyar

Wygląd

Sidebar Navigation

Node API

Test Runner

Metadane Zadań

Rozszerzanie reporterów

Niestandardowa Pula

Na tej stronie

Niestandardowa Pula ​

WARNING

To jest zaawansowane API. Jeśli chcesz tylko uruchamiać testy, prawdopodobnie tego nie potrzebujesz. Jest ono używane głównie przez autorów bibliotek.

Vitest uruchamia testy w pulach. Domyślnie dostępne są następujące pule:

  • threads do uruchamiania testów przy użyciu node:worker_threads (izolacja jest zapewniana przez nowy kontekst wątku)
  • forks do uruchamiania testów przy użyciu node:child_process (izolacja jest zapewniana przez nowy proces child_process.fork)
  • vmThreads do uruchamiania testów przy użyciu node:worker_threads (izolacja jest zapewniana przez moduł vm zamiast nowego kontekstu roboczego)
  • browser do uruchamiania testów przy użyciu dostawców przeglądarkowych
  • typescript do sprawdzania typów w testach

Możesz zdefiniować własną pulę, podając ścieżkę do pliku:

ts
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    // domyślnie uruchomi każdy plik z niestandardową pulą
    pool: './my-custom-pool.ts',
    // możesz przekazać opcje za pomocą obiektu `poolOptions`
    poolOptions: {
      myCustomPool: {
        customProperty: true,
      },
    },
    // możesz również określić pulę dla podzbioru plików
    poolMatchGlobs: [['**/*.custom.test.ts', './my-custom-pool.ts']],
  },
});

API ​

Plik określony w opcji pool powinien eksportować funkcję (może być asynchroniczna), która przyjmuje interfejs Vitest jako swój pierwszy argument. Ta funkcja musi zwrócić obiekt zgodny z interfejsem ProcessPool:

ts
import { ProcessPool, WorkspaceProject } from 'vitest/node';

export interface ProcessPool {
  name: string;
  runTests: (
    files: [project: WorkspaceProject, testFile: string][],
    invalidates?: string[]
  ) => Promise<void>;
  collectTests: (
    files: [project: WorkspaceProject, testFile: string][],
    invalidates?: string[]
  ) => Promise<void>;
  close?: () => Promise<void>;
}

Funkcja jest wywoływana tylko raz, chyba że konfiguracja serwera została zaktualizowana. Zazwyczaj dobrym rozwiązaniem jest zainicjowanie w niej wszystkiego, co jest potrzebne do testów, i ponowne wykorzystywanie tych zasobów przy każdym wywołaniu runTests.

Vitest wywołuje runTests, gdy nowe testy są zaplanowane do uruchomienia. Nie wywoła jej, jeśli tablica files jest pusta. Pierwszym argumentem jest tablica krotek (ang. tuple), gdzie pierwszy element to referencja do projektu workspace'u, a drugi to bezwzględna ścieżka do pliku testowego. Pliki są sortowane za pomocą sequencer przed wywołaniem runTests. Choć mało prawdopodobne, ten sam plik może pojawić się dwukrotnie, ale zawsze będzie powiązany z innym projektem. Jest to realizowane za pomocą konfiguracji vitest.workspace.ts.

Vitest zaczeka z zakończeniem uruchomienia testów, aż funkcja runTests zostanie wykonana (tzn. wyemituje zdarzenie onFinished dopiero po zakończeniu działania runTests).

Jeśli używasz niestandardowej puli, musisz samodzielnie dostarczyć pliki testowe i ich wyniki - możesz w tym celu skorzystać z vitest.state, a szczególnie z funkcji collectFiles i updateTasks. Vitest używa funkcji startTests z pakietu @vitest/runner, aby to zrobić.

Vitest wywoła collectTests, jeśli zostanie wywołane vitest.collect lub vitest list za pomocą polecenia CLI. Działa to tak samo jak runTests, ale nie musisz uruchamiać funkcji zwrotnych testów, wystarczy zgłosić ich zadania, wywołując vitest.state.collectFiles(files).

Aby komunikować się między różnymi procesami, możesz utworzyć obiekt metod przy użyciu createMethodsRPC z vitest/node i użyć dowolnej formy komunikacji, którą preferujesz. Na przykład, aby użyć WebSockets z birpc, możesz napisać coś w tym stylu:

ts
import { createBirpc } from 'birpc';
import { parse, stringify } from 'flatted';
import { createMethodsRPC, WorkspaceProject } from 'vitest/node';

function createRpc(project: WorkspaceProject, wss: WebSocketServer) {
  return createBirpc(createMethodsRPC(project), {
    post: msg => wss.send(msg),
    on: fn => wss.on('message', fn),
    serialize: stringify,
    deserialize: parse,
  });
}

Aby upewnić się, że każdy test został uwzględniony, wywołaj ctx.state.collectFiles i przekaż zebrane dane do reporterów Vitest:

ts
async function runTests(project: WorkspaceProject, tests: string[]) {
  // ... uruchamianie testów, wyniki zapisywane w "files" i "tasks"
  const methods = createMethodsRPC(project);
  await methods.onCollected(files);
  // większość reporterów opiera się na aktualizacji wyników za pomocą "onTaskUpdate"
  await methods.onTaskUpdate(tasks);
}

Możesz znaleźć prosty przykład w pool/custom-pool.ts.

Pager
Poprzednia stronaRozszerzanie reporterów

Opublikowano na licencji MIT.

Copyright (c) 2024 Mithril Contributors

https://v2.vitest.dev/advanced/pool

Opublikowano na licencji MIT.

Copyright (c) 2024 Mithril Contributors