Konfiguracja Vitest

Konfiguracja

vitest odczyta Twój główny plik konfiguracyjny vite.config.ts, jeśli jest dostępny, aby dopasować wtyczki i ustawienia do Twojej aplikacji Vite. Jeśli potrzebujesz innej konfiguracji do testowania lub Twoja aplikacja nie bazuje na Vite, możesz:

Utworzyć vitest.config.ts, który będzie miał wyższy priorytet i zastąpi konfigurację z vite.config.ts.
Przekazać opcję --config do CLI, np. vitest --config ./path/to/vitest.config.ts.
Użyć process.env.VITEST lub właściwości mode w defineConfig (ustawionej na test/benchmark, jeśli nie zostanie nadpisane), aby warunkowo zastosować inną konfigurację w vite.config.ts.

Aby skonfigurować vitest, dodaj sekcję test w konfiguracji Vite. Konieczne będzie również dodanie referencji do typów Vitest, używając dyrektywy z trzema ukośnikami na górze pliku konfiguracyjnego, jeśli importujesz defineConfig z samego vite.

Używając defineConfig z vite, postępuj zgodnie z poniższym przykładem:

/// <reference types="vitest" />
import { defineConfig } from 'vite';

export default defineConfig({
  test: {
    // ...
  },
});

Używając defineConfig z vitest/config, postępuj zgodnie z tym przykładem:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    // ...
  },
});

Możesz odczytać domyślne opcje Vitest i je rozszerzyć, jeśli zajdzie taka potrzeba:

import { configDefaults, defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    exclude: [...configDefaults.exclude, 'packages/template/*'],
  },
});

W przypadku używania oddzielnego pliku vitest.config.js, możesz również rozszerzyć opcje Vite z innego pliku konfiguracyjnego:

import { defineConfig, mergeConfig } from 'vitest/config';
import viteConfig from './vite.config';

export default mergeConfig(
  viteConfig,
  defineConfig({
    test: {
      exclude: ['packages/template/*'],
    },
  })
);

WARNING

Funkcja pomocnicza mergeConfig jest dostępna w Vitest od wersji 0.30.0. Możesz ją importować bezpośrednio z vite, jeśli używasz starszej wersji.

Jeżeli konfiguracja Vite jest zdefiniowana jako funkcja, możesz ją zdefiniować w następujący sposób:

import { defineConfig, mergeConfig } from 'vitest/config';
import viteConfig from './vite.config';

export default defineConfig(configEnv =>
  mergeConfig(
    viteConfig(configEnv),
    defineConfig({
      test: {
        exclude: ['packages/template/*'],
      },
    })
  )
);

Opcje

TIP

Poza wymienionymi opcjami, możesz także użyć dowolnej opcji konfiguracyjnej z Vite. Na przykład define do definiowania zmiennych globalnych lub resolve.alias do definiowania aliasów.

TIP

Opcje konfiguracyjne, które nie są wspierane w projektach przestrzeni roboczej, są oznaczone znakiem *.

include

Typ: string[]
Domyślnie: ['**/*.{test,spec}.?(c|m)[jt]s?(x)']

Wzorce glob używane do wyszukiwania plików testowych, które mają zostać uwzględnione podczas uruchamiania testów.

exclude

Typ: string[]
Domyślnie: ['**/node_modules/**', '**/dist/**', '**/cypress/**', '**/.{idea,git,cache,output,temp}/**', '**/{karma,rollup,webpack,vite,vitest,jest,ava,babel,nyc,cypress,tsup,build}.config.*']

Wzorce glob używane do wykluczania plików podczas uruchamiania testów.

includeSource

Typ: string[]
Domyślnie: []

Wzorce glob dla plików testowych znajdujących się w kodzie źródłowym.

Po zdefiniowaniu, Vitest uruchomi wszystkie pasujące pliki zawierające import.meta.vitest.

server

Typ: { sourcemap?, deps?, ... }
Wersja: Od Vitest 0.34.0

Opcje serwera Vite-Node.

server.sourcemap

Typ: 'inline' | boolean
Domyślnie: 'inline'

Wstrzykuje mapy źródłowe (sourcemaps) bezpośrednio do modułów (w kod źródłowy).

server.debug

Typ: { dumpModules?, loadDumppedModules? }

Opcje debugowania Vite-Node.

server.debug.dumpModules

Typ: boolean | string

Zapisuje przetworzony moduł do systemu plików. Przekazanie ciągu znaków spowoduje zapis do określonej ścieżki.

server.debug.loadDumppedModules

Typ: boolean

Odczytuje zapisany moduł z systemu plików, jeśli taki istnieje. Przydatne do debugowania poprzez modyfikowanie zrzutu z systemu plików.

server.deps

Typ: { external?, inline?, ... }

Opcje konfiguracji rozwiązywania zależności.

server.deps.external

Typ: (string | RegExp)[]
Domyślnie: [/\/node_modules\//]

Eksternalizacja oznacza, że Vite pominie dany pakiet i użyje natywnego Node.js. Eksternalizowane zależności nie będą podlegać transformacjom i resolverom Vite, więc nie obsługują HMR przy przeładowaniu. Domyślnie wszystkie pakiety wewnątrz node_modules są eksternalizowane.

Te opcje obsługują nazwy pakietów tak, jak są zapisane w node_modules lub określone wewnątrz deps.moduleDirectories. Na przykład pakiet @company/some-name znajdujący się wewnątrz packages/some-name powinien być określony jako some-name, a packages powinien być uwzględniony w deps.moduleDirectories. Vitest zawsze sprawdza ścieżkę do pliku, a nie rzeczywistą nazwę pakietu.

Jeśli używasz wyrażenia regularnego (regexp), Vitest wywołuje je na ścieżce pliku, a nie na nazwie pakietu.

server.deps.inline

Typ: (string | RegExp)[] | true
Domyślnie: []

Vite przetworzy moduły inline. Może to pomóc w obsłudze pakietów, które dostarczają .js w formacie ESM (którego Node nie może obsłużyć).

Jeśli ustawiono na true, każda zależność zostanie wbudowana. Wszystkie zależności określone w ssr.noExternal zostaną domyślnie wbudowane.

server.deps.fallbackCJS

Typ: boolean
Domyślnie: false

Gdy zależność jest prawidłowym pakietem ESM, spróbuj odgadnąć wersję CJS na podstawie ścieżki. Może to być pomocne, jeśli zależność ma nieprawidłowy plik ESM.

Może to potencjalnie prowadzić do rozbieżności, jeśli pakiet implementuje inną logikę w trybach ESM i CJS.

server.deps.cacheDir

Typ: string
Domyślnie: 'node_modules/.vite'

Katalog do przechowywania plików cache.

deps

Typ: { optimizer?, registerNodeLoader?, ... }

Opcje konfiguracji rozwiązywania zależności.

deps.optimizer

Typ: { ssr?, web? }
Wersja: Od Vitest 0.34.0
Zobacz także: Opcje Optymalizacji Zależności

Włącza optymalizację zależności. Jeśli masz wiele testów, może to poprawić ich wydajność. Przed Vitest 0.34.0 nazywało się to deps.experimentalOptimizer.

Gdy Vitest napotka zewnętrzną bibliotekę, która została uwzględniona w include, zostanie ona spakowana do jednego pliku za pomocą esbuild i zaimportowana jako pojedynczy moduł. Jest to korzystne z kilku powodów:

Importowanie pakietów zawierających dużą liczbę importów jest kosztowne. Pakując je do jednego pliku, możemy zaoszczędzić dużo czasu.
Importowanie bibliotek UI jest kosztowne, ponieważ nie są one przeznaczone do uruchamiania wewnątrz Node.js.
Twoja konfiguracja alias jest teraz respektowana wewnątrz spakowanych pakietów.
Kod w testach będzie działał w sposób zbliżony do tego, jak działa w przeglądarce.

Należy pamiętać, że tylko pakiety w opcji deps.optimizer?.[mode].include są pakowane (niektóre wtyczki wypełniają to automatycznie, jak Svelte). Możesz przeczytać więcej o dostępnych opcjach w dokumentacji Vite (Vitest nie obsługuje opcji disable i noDiscovery). Domyślnie Vitest używa optimizer.web dla środowisk jsdom i happy-dom, a optimizer.ssr dla środowisk node i edge, ale można to skonfigurować za pomocą transformMode.

Ta opcja rozszerza również Twoją konfigurację optimizeDeps (dla web Vitest rozszerzy optimizeDeps, dla ssr - ssr.optimizeDeps). Jeśli przedefiniujesz opcję include/exclude w deps.optimizer, rozszerzy ona Twoje optimizeDeps podczas uruchamiania testów. Vitest automatycznie usuwa te same opcje z include, jeśli są one wymienione w exclude.

TIP

Edycja kodu w node_modules w celu debugowania nie będzie możliwa, ponieważ kod znajduje się w katalogu cacheDir lub test.cache.dir. Jeśli chcesz debugować za pomocą instrukcji console.log, edytuj go bezpośrednio lub wymuś ponowne pakowanie za pomocą opcji deps.optimizer?.[mode].force.

deps.optimizer.{mode}.enabled

Typ: boolean
Domyślnie: true, jeśli używasz >= Vite 4.3.2, false w przeciwnym razie

Włącza optymalizację zależności.

WARNING

Ta opcja działa tylko z Vite 4.3.2 i nowszymi.

deps.web

Typ: { transformAssets?, ... }
Wersja: Od Vite 0.34.2

Opcje stosowane do zewnętrznych plików, gdy tryb transformacji jest ustawiony na web. Domyślnie jsdom i happy-dom używają trybu web, podczas gdy środowiska node i edge używają trybu transformacji ssr, więc te opcje nie będą miały wpływu na pliki w tych środowiskach.

Zazwyczaj pliki wewnątrz node_modules są eksternalizowane, ale te opcje wpływają również na pliki w server.deps.external.

deps.web.transformAssets

Typ: boolean
Domyślnie: true

Określa, czy Vitest powinien przetwarzać pliki zasobów (np. .png, .svg, .jpg) i rozwiązywać je w taki sam sposób, jak Vite w przeglądarce.

Ten moduł będzie eksportował domyślnie ścieżkę do zasobu, jeśli nie zostanie podane zapytanie.

WARNING

Obecnie ta opcja działa tylko z pulą experimentalVmThreads.

deps.web.transformCss

Typ: boolean
Domyślnie: true

Czy Vitest ma przetwarzać pliki CSS (np. .css, .scss, .sass) i rozwiązywać je w taki sam sposób, jak Vite w przeglądarce?

Jeśli pliki CSS są wyłączone za pomocą opcji css, ta opcja po prostu wyciszy błędy ERR_UNKNOWN_FILE_EXTENSION.

WARNING

Obecnie ta opcja działa tylko z pulą experimentalVmThreads.

deps.web.transformGlobPattern

Typ: RegExp | RegExp[]
Domyślnie: []

Wzorzec wyrażenia regularnego (Regexp) do dopasowywania zewnętrznych plików, które powinny być przetwarzane.

Domyślnie pliki wewnątrz node_modules są eksternalizowane i nie są przetwarzane, chyba że jest to CSS lub zasób, a odpowiednia opcja nie jest wyłączona.

WARNING

Obecnie ta opcja działa tylko z pulą experimentalVmThreads.

deps.registerNodeLoader*

Typ: boolean
Domyślnie: false

Wykorzystaj eksperymentalny loader Node.js do rozwiązywania importów w eksternalizowanych plikach, z wykorzystaniem algorytmu rozwiązywania Vite.

Jeśli jest wyłączone, Twój alias i <plugin>.resolveId nie wpłyną na importy wewnątrz eksternalizowanych pakietów (domyślnie node_modules).

deps.interopDefault

Typ: boolean
Domyślnie: true

Interpretuj domyślny eksport modułu CJS jako nazwane eksporty. Niektóre zależności pakują tylko moduły CJS i nie używają nazwanych eksportów, które Node.js może statycznie analizować, gdy pakiet jest importowany za pomocą składni import zamiast require. Podczas importowania takich zależności w środowisku Node za pomocą nazwanych eksportów zobaczysz ten błąd:

import { read } from 'fs-jetpack';
         ^^^^
SyntaxError: Named export 'read' not found. The requested module 'fs-jetpack' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export.

Vitest nie przeprowadza analizy statycznej i nie może wykryć błędu przed uruchomieniem kodu. W związku z tym, jeśli ta funkcja jest wyłączona, błąd najprawdopodobniej pojawi się podczas uruchamiania testów:

TypeError: createAsyncThunk is not a function
TypeError: default is not a function

Domyślnie Vitest zakłada wykorzystanie bundlera, aby to obejść i nie zawiedzie, ale możesz wyłączyć to zachowanie ręcznie, jeśli Twój kod nie jest przetwarzany.

deps.moduleDirectories

Typ: string[]
Domyślnie: ['node_modules']

Lista katalogów, które powinny być traktowane jako katalogi modułów. Ta opcja konfiguracyjna wpływa na działanie vi.mock: gdy nie podano fabryki, a ścieżka tego, co mockujesz, pasuje do jednej z wartości moduleDirectories, Vitest spróbuje rozwiązać mock, szukając folderu __mocks__ w korzeniu projektu.

Ta opcja wpłynie również na to, czy dany plik ma być traktowany jako moduł podczas eksternalizacji zależności. Domyślnie Vitest importuje zewnętrzne moduły za pomocą natywnego Node.js, pomijając krok transformacji Vite.

Ustawienie tej opcji zastąpi domyślne ustawienie, jeśli nadal chcesz przeszukiwać node_modules w poszukiwaniu pakietów, dołącz je wraz z innymi opcjami:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    deps: {
      moduleDirectories: ['node_modules', path.resolve('../../packages')],
    },
  },
});

runner

Typ: VitestRunnerConstructor
Domyślnie: node, podczas uruchamiania testów, lub benchmark, podczas uruchamiania benchmarków

Więcej informacji na ten temat znajdziesz w dokumentacji.

benchmark

Typ: { include?, exclude?, ... }

Opcje używane podczas uruchamiania vitest bench.

benchmark.include

Typ: string[]
Domyślnie: ['**/*.{bench,benchmark}.?(c|m)[jt]s?(x)']

Wzorce glob dla plików benchmarków.

benchmark.exclude

Typ: string[]
Domyślnie: ['node_modules', 'dist', '.idea', '.git', '.cache']

Wzorce glob wykluczające pliki benchmarków.

benchmark.includeSource

Typ: string[]
Domyślnie: []

Wzorce glob dla plików benchmarków w kodzie źródłowym. Ta opcja jest podobna do includeSource.

Po zdefiniowaniu, Vitest uruchomi wszystkie pasujące pliki zawierające import.meta.vitest.

benchmark.reporters

Typ: Arrayable<BenchmarkBuiltinReporters | Reporter>
Domyślnie: 'default'

Niestandardowy reporter wyników. Może zawierać jedną lub więcej wbudowanych nazw raportów, instancji reporterów lub ścieżek do niestandardowych reporterów.

benchmark.outputFile

Typ: string | Record<string, string>

Zapisuje wyniki benchmarku do pliku, jeśli została określona opcja --reporter=json. Podając obiekt zamiast ciągu znaków, można zdefiniować indywidualne pliki wyjściowe dla każdego z reporterów.

Aby podać obiekt za pomocą polecenia CLI, użyj następującej składni: --outputFile.json=./path --outputFile.junit=./other-path.

alias

Typ: Record<string, string> | Array<{ find: string | RegExp, replacement: string, customResolver?: ResolverFunction | ResolverObject }>

Zdefiniuj niestandardowe aliasy podczas uruchamiania testów. Zostaną one scalone z aliasami zdefiniowanymi w resolve.alias.

globals

Typ: boolean
Domyślnie: false
CLI: --globals, --globals=false

Domyślnie vitest nie udostępnia globalnych API, aby zachować większą przejrzystość. Jeśli preferujesz używanie globalnych API, tak jak w Jest, możesz przekazać opcję --globals do CLI lub dodać globals: true w konfiguracji.

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

export default defineConfig({
  test: {
    globals: true,
  },
});

Aby TypeScript poprawnie współpracował z globalnymi API, dodaj vitest/globals do pola types w pliku tsconfig.json

json

// tsconfig.json
{
  "compilerOptions": {
    "types": ["vitest/globals"]
  }
}

Jeśli w projekcie używasz już [unplugin-auto-import], możesz go również wykorzystać do automatycznego importowania tych API.

// vite.config.ts
import { defineConfig } from 'vitest/config';
import AutoImport from 'unplugin-auto-import/vite';

export default defineConfig({
  plugins: [
    AutoImport({
      imports: ['vitest'],
      dts: true, // generuj deklarację TypeScript
    }),
  ],
});

environment

Typ: 'node' | 'jsdom' | 'happy-dom' | 'edge-runtime' | string
Domyślnie: 'node'
CLI: --environment=<env>

Określa środowisko, w którym będą uruchamiane testy. Domyślnym środowiskiem w Vitest jest Node.js. W przypadku aplikacji webowych można użyć środowiska emulującego przeglądarkę, takiego jak jsdom lub happy-dom. Do testowania funkcji edge można wykorzystać środowisko edge-runtime.

Można zdefiniować środowisko dla konkretnego pliku testowego, dodając docblock @vitest-environment lub komentarz na początku pliku:

Format docblock:

/**
 * @vitest-environment jsdom
 */

test('użyj jsdom w tym pliku testowym', () => {
  const element = document.createElement('div');
  expect(element).not.toBeNull();
});

Format komentarza:

// @vitest-environment happy-dom

test('użyj happy-dom w tym pliku testowym', () => {
  const element = document.createElement('div');
  expect(element).not.toBeNull();
});

Dla zachowania kompatybilności z Jest, obsługiwany jest również @jest-environment:

/**
 * @jest-environment jsdom
 */

test('użyj jsdom w tym pliku testowym', () => {
  const element = document.createElement('div');
  expect(element).not.toBeNull();
});

Przy uruchamianiu Vitest z flagą --threads=false, testy będą wykonywane w następującej kolejności środowisk: node, jsdom, happy-dom, edge-runtime, custom environments (środowiska niestandardowe). Oznacza to, że testy z tym samym środowiskiem są grupowane, ale nadal wykonywane sekwencyjnie.

Od wersji 0.23.0 można definiować własne, niestandardowe środowiska. Gdy używane jest środowisko inne niż wbudowane, Vitest próbuje załadować pakiet vitest-environment-${name}. Ten pakiet powinien eksportować obiekt o strukturze Environment:

import type { Environment } from 'vitest';

export default <Environment>{
  name: 'custom',
  transformMode: 'ssr',
  setup() {
    // konfiguracja środowiska
    return {
      teardown() {
        // wywoływana po zakończeniu wszystkich testów w tym środowisku
      },
    };
  },
};

Vitest udostępnia również builtinEnvironments poprzez wpis vitest/environments, co umożliwia jego rozszerzenie. Więcej informacji o rozszerzaniu środowisk można znaleźć w naszym przewodniku.

environmentOptions

Typ: Record<'jsdom' | string, unknown>
Wartość domyślna: {}

Opcje przekazywane do metody setup bieżącego environment. Domyślnie, można konfigurować opcje tylko dla JSDOM, jeśli jest on używany jako środowisko testowe.

environmentMatchGlobs

Typ: [string, EnvironmentName][]
Wartość domyślna: []

Automatycznie przypisuje środowisko na podstawie wzorców glob. Używane jest pierwsze pasujące środowisko.

Przykład:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    environmentMatchGlobs: [
      // wszystkie testy w katalogu tests/dom będą uruchamiane w jsdom
      ['tests/dom/**', 'jsdom'],
      // wszystkie testy w tests/ z .edge.test.ts będą uruchamiane w edge-runtime
      ['**/*.edge.test.ts', 'edge-runtime'],
      // ...
    ],
  },
});

poolMatchGlobs

Typ: [string, 'threads' | 'child_process' | 'experimentalVmThreads'][]
Wartość domyślna: []
Wersja: Od Vitest 0.29.4

Automatycznie przypisuje pulę, w której będą uruchamiane testy, na podstawie wzorców glob. Używane jest pierwsze dopasowanie.

Przykład:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolMatchGlobs: [
      // wszystkie testy w katalogu "worker-specific" będą uruchamiane wewnątrz workera, tak jakby włączono dla nich `--threads`
      ['**/tests/worker-specific/**', 'threads'],
      // uruchom wszystkie testy w katalogu "browser" w rzeczywistej przeglądarce
      ['**/tests/browser/**', 'browser'],
      // wszystkie inne testy będą uruchamiane na podstawie opcji "browser.enabled" i "threads", jeśli nie określono innych wzorców glob
      // ...
    ],
  },
});

update*

Typ: boolean
Wartość domyślna: false
CLI: -u, --update, --update=false

Aktualizuje pliki snapshotów. Powoduje to zaktualizowanie wszystkich zmienionych migawek i usunięcie przestarzałych.

watch*

Typ: boolean
Wartość domyślna: true
CLI: -w, --watch, --watch=false

Włącza tryb obserwowania zmian.

root

Typ: string
CLI: -r <path>, --root=<path>

Katalog główny projektu.

reporters*

Typ: Reporter | Reporter[]
Wartość domyślna: 'default'
CLI: --reporter=<name>, --reporter=<name1> --reporter=<name2>

Niestandardowe reportery dla wyjścia. Reportery mogą być instancją Reportera lub ciągiem znaków, aby wybrać wbudowane reportery:

'default' - układa zestawy testów w strukturę, gdy przejdą
'basic' - udostępnia reportera podobnego do domyślnego w CI
'verbose' - zachowuje pełne drzewo zadań widoczne
'dot' - pokazuje każde zadanie jako pojedynczą kropkę
'junit' - Reporter JUnit XML (można skonfigurować nazwę tagu testsuites za pomocą zmiennej środowiskowej VITEST_JUNIT_SUITE_NAME i właściwość tagu classname za pomocą VITEST_JUNIT_CLASSNAME)
'json' - generuje proste podsumowanie JSON
'html' - tworzy raport HTML na podstawie @vitest/ui
'hanging-process' - pokazuje listę zawieszonych procesów, jeśli Vitest nie może bezpiecznie zakończyć procesu. Może to być operacja wymagająca dużej ilości zasobów, należy ją włączać tylko wtedy, gdy Vitest konsekwentnie nie może zakończyć procesu
ścieżka do niestandardowego reportera (np. './path/to/reporter.ts', '@scope/reporter')

outputFile*

Typ: string | Record<string, string>
CLI: --outputFile=<path>, --outputFile.json=./path

Zapisuje wyniki testów w pliku, gdy określono również opcję --reporter=json, --reporter=html lub --reporter=junit. Podając obiekt zamiast ciągu znaków, można zdefiniować indywidualne wyjścia dla każdego reportera.

experimentalVmThreads

Typ: boolean
CLI: --experimentalVmThreads, --experimental-vm-threads
Wersja: Od Vitest 0.34.0

Uruchamia testy za pomocą kontekstu VM (wewnątrz środowiska sandbox) w puli workerów.

Przyspiesza to wykonywanie testów, ale moduł VM jest niestabilny podczas uruchamiania kodu ESM. W testach mogą wystąpić wycieki pamięci - aby temu zapobiec, rozważ ręczną edycję wartości experimentalVmWorkerMemoryLimit.

WARNING

Uruchamianie kodu w sandboxie ma pewne zalety (szybsze testy), ale wiąże się również z szeregiem wad.

Globalne zmienne w natywnych modułach, takie jak (fs, path itp.), różnią się od zmiennych globalnych obecnych w środowisku testowym. W rezultacie każdy błąd zgłoszony przez te moduły natywne będzie odwoływał się do innego konstruktora Error w porównaniu z tym używanym w kodzie:

try {
  fs.writeFileSync('/doesnt exist');
} catch (err) {
  console.log(err instanceof Error); // false
}

Importowanie modułów ES buforuje je na czas nieokreślony, co powoduje wycieki pamięci, jeśli masz dużo kontekstów (plików testowych). W Node.js nie ma API, które czyści tę pamięć podręczną.
Dostęp do zmiennych globalnych trwa dłużej w środowisku sandbox.

Należy pamiętać o tych problemach podczas korzystania z tej opcji. Zespół Vitest nie może naprawić żadnego z tych problemów.

experimentalVmWorkerMemoryLimit

Typ: string | number
CLI: --experimentalVmWorkerMemoryLimit, --experimental-vm-worker-memory-limit
Wartość domyślna: 1 / Liczba rdzeni procesora
Wersja: Od Vitest 0.34.0

Określa limit pamięci dla workerów przed ich ponownym użyciem. Ta wartość silnie zależy od środowiska, więc zaleca się określenie jej ręcznie, zamiast polegać na wartości domyślnej.

Ta opcja wpływa tylko na workerów, którzy uruchamiają testy w kontekście VM.

TIP

Implementacja opiera się na workerIdleMemoryLimit z Jest.

Limit można określić na wiele różnych sposobów, a niezależnie od wyniku, Math.floor jest używany do przekształcenia go w wartość całkowitą:

<= 1 - Zakłada się, że wartość jest procentem pamięci systemowej. Zatem 0.5 ustawia limit pamięci workera na połowę całkowitej pamięci systemowej
\> 1 - Zakłada się, że jest to stała wartość bajtowa. Ze względu na poprzednią regułę, jeśli chcesz wartość 1 bajta (nie wiadomo dlaczego), możesz użyć 1.1.
Z jednostkami
- 50% - Jak wyżej, procent całkowitej pamięci systemowej
- 100KB, 65MB itp. - Z jednostkami oznaczającymi stały limit pamięci.
  - K / KB - Kilobajty (x1000)
  - KiB - Kibibajty (x1024)
  - M / MB - Megabajty
  - MiB - Mebibajty
  - G / GB - Gigabajty
  - GiB - Gibibajty

WARNING

Limit pamięci oparty na procentach nie działa na workerach Linux CircleCI z powodu nieprawidłowo zgłaszanej pamięci systemowej.

threads

Typ: boolean
Wartość domyślna: true
CLI: --threads, --threads=false

Włącza wielowątkowość za pomocą tinypool (lekkiego forka Piscina). Przed Vitest 0.29.0 Vitest nadal uruchamiał testy wewnątrz wątku roboczego, nawet jeśli ta opcja była wyłączona. Od 0.29.0, jeśli ta opcja jest wyłączona, Vitest używa child_process do tworzenia procesu w celu uruchomienia testów wewnątrz, co oznacza, że można użyć process.chdir i innych API, które nie były dostępne wewnątrz workerów. Jeśli chcesz powrócić do poprzedniego zachowania, użyj zamiast tego opcji --single-thread.

Wyłączenie tej opcji powoduje, że wszystkie testy są uruchamiane w wielu procesach potomnych.

singleThread

Typ: boolean
Wartość domyślna: false
Wersja: Od Vitest 0.29.0

Uruchamia wszystkie testy z tym samym środowiskiem wewnątrz jednego wątku roboczego. Spowoduje to wyłączenie wbudowanej izolacji modułów (kod źródłowy lub kod wstawiony nadal będzie ponownie oceniany dla każdego testu), ale może poprawić wydajność testów. Przed Vitest 0.29.0 było to równoważne użyciu --no-threads.

WARNING

Mimo że ta opcja wymusi uruchamianie testów jeden po drugim, różni się od --runInBand z Jest. Vitest używa workerów nie tylko do uruchamiania testów równolegle, ale także do zapewnienia izolacji. Wyłączenie tej opcji spowoduje, że testy będą uruchamiane sekwencyjnie, ale w tym samym globalnym kontekście, więc musisz sam zapewnić izolację.

Może to prowadzić do różnych problemów, jeśli polegasz na stanie globalnym (co jest typowe dla frameworków frontendowych) lub jeśli kod wymaga, aby środowisko było zdefiniowane oddzielnie dla każdego testu. Ale może to przyspieszyć testy (do 3 razy szybciej), które niekoniecznie polegają na stanie globalnym lub mogą go łatwo ominąć.

maxThreads*

Typ: number
Wartość domyślna: dostępne rdzenie CPU

Maksymalna liczba wątków. Można również użyć zmiennej środowiskowej VITEST_MAX_THREADS.

minThreads*

Typ: number
Wartość domyślna: dostępne rdzenie CPU

Minimalna liczba wątków. Można również użyć zmiennej środowiskowej VITEST_MIN_THREADS.

useAtomics*

Typ: boolean
Wartość domyślna: false
Wersja: Od Vitest 0.28.3

Używa Atomics do synchronizacji wątków.

Może to poprawić wydajność w niektórych przypadkach, ale może powodować błąd segmentacji w starszych wersjach Node.

testTimeout

Typ: number
Wartość domyślna: 5000
CLI: --test-timeout=5000

Domyślny limit czasu testu w milisekundach.

hookTimeout

Typ: number
Wartość domyślna: 10000

Domyślny limit czasu hooka w milisekundach.

teardownTimeout*

Typ: number
Wartość domyślna: 10000

Domyślny limit czasu oczekiwania na zamknięcie, gdy Vitest się wyłącza, w milisekundach.

silent*

Typ: boolean
Wartość domyślna: false
CLI: --silent, --silent=false

Wycisza wyjście konsoli z testów.

setupFiles

Typ: string | string[]

Ścieżka do plików konfiguracyjnych. Będą one uruchamiane przed każdym plikiem testowym.

INFO

Zmiana plików konfiguracyjnych spowoduje ponowne uruchomienie wszystkich testów.

Można użyć process.env.VITEST_POOL_ID (ciąg znaków podobny do liczby całkowitej) wewnątrz, aby odróżnić wątki (zawsze będzie to '1', jeśli uruchomiono z threads: false).

TIP

Pamiętaj, że jeśli uruchamiasz --threads=false, ten plik konfiguracyjny zostanie uruchomiony w tym samym globalnym zakresie wiele razy. Oznacza to, że uzyskujesz dostęp do tego samego obiektu globalnego przed każdym testem, więc upewnij się, że nie robisz tego samego więcej niż potrzebujesz.

Na przykład możesz polegać na zmiennej globalnej:

import { config } from '@some-testing-lib';

if (!globalThis.defined) {
  config.plugins = [myCoolPlugin];
  computeHeavyThing();
  globalThis.defined = true;
}

// funkcje hook są resetowane przed każdą grupą testów
afterEach(() => {
  cleanup();
});

globalThis.resetBeforeEachTest = true;

globalSetup

Typ: string | string[]

Ścieżka do globalnych plików konfiguracyjnych, względem katalogu projektu.

Globalny plik konfiguracyjny może eksportować nazwane funkcje setup i teardown lub funkcję default, która zwraca funkcję teardown (przykład).

INFO

Możliwe jest wiele globalnych plików konfiguracyjnych. Funkcje setup i teardown są wykonywane sekwencyjnie, a teardown w odwrotnej kolejności.

WARNING

Należy pamiętać, że globalna konfiguracja działa w innym zakresie globalnym, więc testy nie mają dostępu do zmiennych zdefiniowanych tutaj.

watchExclude*

Typ: string[]
Wartość domyślna: ['**/node_modules/**', '**/dist/**']

Wzorzec glob dla ścieżek plików, które mają być ignorowane, aby nie wywoływać ponownego uruchomienia obserwacji.

forceRerunTriggers*

Typ: string[]
Wartość domyślna: ['**/package.json/**', '**/vitest.config.*/**', '**/vite.config.*/**']

Wzorzec glob dla ścieżek plików, które spowodują ponowne uruchomienie całego zestawu testów. W połączeniu z argumentem --changed uruchomi cały zestaw testów, jeśli wyzwalacz zostanie znaleziony w git diff.

Przydatne, jeśli testujesz wywoływanie poleceń CLI, ponieważ Vite nie może skonstruować grafu modułów:

test('execute a script', async () => {
  // Vitest nie może ponownie wykonać tego testu, jeśli zmieni się zawartość `dist/index.js`
  await execa('node', ['dist/index.js']);
});

TIP

Upewnij się, że twoje pliki nie są wykluczone przez watchExclude.

isolate

Typ: boolean
Wartość domyślna: true
CLI: --isolate, --isolate=false

Izoluje środowisko każdego pliku testowego. Nie działa, jeśli wyłączysz opcję --threads.

Ta opcja nie wpływa na experimentalVmThreads.

coverage*

Możesz użyć v8, istanbul lub własnego rozwiązania do pokrycia kodu do zbierania danych o pokryciu kodu testami.

Możesz przekazywać opcje pokrycia kodu do CLI za pomocą notacji z kropkami:

npx vitest --coverage.enabled --coverage.provider=istanbul --coverage.all

WARNING

Jeśli używasz opcji pokrycia kodu z notacją z kropkami, pamiętaj, aby określić --coverage.enabled. Nie używaj pojedynczej opcji --coverage w takim przypadku.

coverage.provider

Typ: 'v8' | 'istanbul' | 'custom'
Wartość domyślna: 'v8'
CLI: --coverage.provider=<dostawca>

Użyj provider, aby wybrać narzędzie do zbierania danych o pokryciu kodu.

coverage.enabled

Typ: boolean
Wartość domyślna: false
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.enabled, --coverage.enabled=false

Włącza zbieranie informacji o pokryciu kodu testami. Można ją nadpisać za pomocą opcji CLI --coverage.

coverage.include

Typ: string[]
Wartość domyślna: ['**']
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.include=<ścieżka>, --coverage.include=<ścieżka1> --coverage.include=<ścieżka2>

Lista plików uwzględnionych w pokryciu kodu, określona jako wzorce Glob.

coverage.extension

Typ: string | string[]
Wartość domyślna: ['.js', '.cjs', '.mjs', '.ts', '.mts', '.cts', '.tsx', '.jsx', '.vue', '.svelte']
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.extension=<rozszerzenie>, --coverage.extension=<rozszerzenie1> --coverage.extension=<rozszerzenie2>

coverage.exclude

Typ: string[]
Wartość domyślna:

[
  'coverage/**',
  'dist/**',
  'packages/*/test?(s)/**',
  '**/*.d.ts',
  '**/virtual:*',
  '**/__x00__*',
  '**/\x00*',
  'cypress/**',
  'test?(s)/**',
  'test?(-*).?(c|m)[jt]s?(x)',
  '**/*{.,-}{test,spec}.?(c|m)[jt]s?(x)',
  '**/__tests__/**',
  '**/{karma,rollup,webpack,vite,vitest,jest,ava,babel,nyc,cypress,tsup,build}.config.*',
  '**/vitest.{workspace,projects}.[jt]s?(on)',
  '**/.{eslint,mocha,prettier}rc.{?(c|m)js,yml}',
];

Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.exclude=<ścieżka>, --coverage.exclude=<ścieżka1> --coverage.exclude=<ścieżka2>

Lista plików wykluczonych z pokrycia kodu, określona jako wzorce Glob.

coverage.all

Typ: boolean
Wartość domyślna: false
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.all, --coverage.all=false

Czy uwzględniać wszystkie pliki, w tym te nieprzetestowane, w raporcie pokrycia kodu.

coverage.clean

Typ: boolean
Wartość domyślna: true
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.clean, --coverage.clean=false

Usuwa wyniki pokrycia kodu przed uruchomieniem testów.

coverage.cleanOnRerun

Typ: boolean
Wartość domyślna: true
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.cleanOnRerun, --coverage.cleanOnRerun=false

Czyści raport pokrycia kodu przy ponownym uruchomieniu w trybie obserwowania zmian (watch).

coverage.reportsDirectory

Typ: string
Wartość domyślna: './coverage'
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.reportsDirectory=<ścieżka>

Katalog, w którym zapisywane są raporty pokrycia kodu.

coverage.reporter

Typ: string | string[] | [string, {}][]
Wartość domyślna: ['text', 'html', 'clover', 'json']
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.reporter=<reporter>, --coverage.reporter=<reporter1> --coverage.reporter=<reporter2>

Moduły raportujące pokrycie kodu do użycia. Zobacz dokumentację istanbul dla szczegółowej listy wszystkich reporterów. Zobacz @types/istanbul-reporter dla szczegółów dotyczących opcji specyficznych dla reportera.

Reporter może być zdefiniowany na trzy sposoby:

Pojedynczy reporter: { reporter: 'html' }
Wiele reporterów bez opcji: { reporter: ['html', 'json'] }

Pojedynczy lub wielu reporterów z opcjami:

{
  reporter: [
    ['lcov', { projectRoot: './src' }],
    ['json', { file: 'coverage.json' }],
    ['text'],
  ];
}

Od Vitest 0.31.0 możesz sprawdzić raport pokrycia kodu w Vitest UI: sprawdź Vitest UI Coverage aby uzyskać więcej szczegółów.

coverage.reportOnFailure

Typ: boolean
Wartość domyślna: false (od Vitest 0.34.0)
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.reportOnFailure, --coverage.reportOnFailure=false
Wersja: Od Vitest 0.31.2

Generuj raport pokrycia kodu nawet wtedy, gdy testy zakończą się niepowodzeniem.

coverage.allowExternal

Typ: boolean
Wartość domyślna: false
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.allowExternal, --coverage.allowExternal=false

Zbieraj dane o pokryciu kodu dla plików spoza katalogu root projektu.

coverage.skipFull

Typ: boolean
Wartość domyślna: false
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.skipFull, --coverage.skipFull=false

Nie pokazuj plików ze 100% pokryciem instrukcji, gałęzi i funkcji.

coverage.perFile

Typ: boolean
Wartość domyślna: false
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.perFile, --coverage.perFile=false

Sprawdź progi pokrycia dla każdego pliku. Zobacz lines, functions, branches i statements dla definicji progów.

coverage.thresholdAutoUpdate

Typ: boolean
Wartość domyślna: false
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.thresholdAutoUpdate=<boolean>

Aktualizuj wartości progowe lines, functions, branches i statements w pliku konfiguracyjnym, gdy bieżące pokrycie przekracza skonfigurowane progi. Ta opcja pomaga w utrzymaniu progów, gdy pokrycie jest poprawiane.

coverage.lines

Typ: number
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.lines=<liczba>

Próg pokrycia dla linii. Zobacz dokumentację istanbul aby uzyskać więcej informacji.

coverage.functions

Typ: number
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.functions=<liczba>

Próg pokrycia dla funkcji. Zobacz dokumentację istanbul aby uzyskać więcej informacji.

coverage.branches

Typ: number
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.branches=<liczba>

Próg pokrycia dla gałęzi. Zobacz dokumentację istanbul aby uzyskać więcej informacji.

coverage.statements

Typ: number
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.statements=<liczba>

Próg pokrycia dla instrukcji. Zobacz dokumentację istanbul aby uzyskać więcej informacji.

coverage.100

Typ: boolean
Wartość domyślna: false
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.100, --coverage.100=false

Odpowiednik --coverage.lines 100 --coverage.functions 100 --coverage.branches 100 --coverage.statements 100.

coverage.ignoreClassMethods

Typ: string[]
Wartość domyślna: []
Dostępne dla dostawców: 'istanbul'
CLI: --coverage.ignoreClassMethods=<metoda>

Ustaw na tablicę nazw metod klas, które mają być ignorowane podczas obliczania pokrycia kodu. Zobacz dokumentację istanbul aby uzyskać więcej informacji.

coverage.watermarks

Typ:

{
  statements?: [number, number],
  functions?: [number, number],
  branches?: [number, number],
  lines?: [number, number]
}

Wartość domyślna:

{
  statements: [50, 80],
  functions: [50, 80],
  branches: [50, 80],
  lines: [50, 80]
}

Dostępne dla dostawców: 'v8' | 'istanbul'

Poziomy progowe dla instrukcji, linii, gałęzi i funkcji. Zobacz dokumentację istanbul aby uzyskać więcej informacji.

coverage.customProviderModule

Typ: string
Dostępne dla dostawców: 'custom'
CLI: --coverage.customProviderModule=<ścieżka lub nazwa modułu>

Określa nazwę modułu lub ścieżkę do niestandardowego dostawcy pokrycia kodu. Zobacz Przewodnik - Niestandardowy dostawca pokrycia kodu aby uzyskać więcej informacji.

testNamePattern*

Typ: string | RegExp
CLI: -t <wzorzec>, --testNamePattern=<wzorzec>, --test-name-pattern=<wzorzec>

Uruchom testy, których pełne nazwy pasują do wzorca. Jeśli dodasz OnlyRunThis do tej właściwości, testy, które nie zawierają słowa OnlyRunThis w nazwie, zostaną pominięte.

import { expect, test } from 'vitest';

// uruchamiany
test('OnlyRunThis', () => {
  expect(true).toBe(true);
});

// pomijany
test('doNotRun', () => {
  expect(true).toBe(true);
});

open*

Typ: boolean
Wartość domyślna: false
CLI: --open, --open=false

Otwiera Vitest UI (WIP - w trakcie realizacji)

api

Typ: boolean | number
Wartość domyślna: false
CLI: --api, --api.port, --api.host, --api.strictPort

Uruchamia serwer API nasłuchujący na porcie. Gdy ustawione na true, domyślny port to 51204.

browser

Typ: { enabled?, name?, provider?, headless?, api?, slowHijackESM? }
Wartość domyślna: { enabled: false, headless: process.env.CI, api: 63315 }
Wersja: Od Vitest 0.29.4
CLI: --browser, --browser=<nazwa>, --browser.name=chrome --browser.headless

Uruchom testy Vitest w przeglądarce. Domyślnie używamy WebdriverIO do uruchamiania testów, ale można to skonfigurować za pomocą opcji browser.provider.

NOTE

Przeczytaj więcej o testowaniu w prawdziwej przeglądarce na stronie przewodnika.

WARNING

To jest funkcja eksperymentalna. Zmiany powodujące niezgodność mogą nie być zgodne z semver, proszę przypiąć wersję Vitest podczas korzystania z niej.

browser.enabled

Typ: boolean
Wartość domyślna: false
CLI: --browser, --browser.enabled=false

Domyślnie uruchamia wszystkie testy w przeglądarce. Można to nadpisać za pomocą opcji poolMatchGlobs.

browser.name

Typ: string
CLI: --browser=safari

Uruchom wszystkie testy w określonej przeglądarce. Możliwe opcje u różnych dostawców:

webdriverio: firefox, chrome, edge, safari
playwright: firefox, webkit, chromium
custom: dowolny ciąg znaków, który zostanie przekazany do dostawcy

browser.headless

Typ: boolean
Wartość domyślna: process.env.CI
CLI: --browser.headless, --brower.headless=false

Uruchamia przeglądarkę w trybie headless (bez interfejsu graficznego). Jeśli uruchamiasz Vitest w CI (integracja ciągła), zostanie to domyślnie włączone.

browser.api

Typ: number | { port?, strictPort?, host? }
Wartość domyślna: 63315
CLI: --browser.api=63315, --browser.api.port=1234, --browser.api.host=example.com

Skonfiguruj opcje dla serwera Vite, który obsługuje kod w przeglądarce. Nie wpływa na opcję test.api.

browser.provider

Typ: 'webdriverio' | 'playwright' | string
Wartość domyślna: 'webdriverio'
CLI: --browser.provider=playwright

Ścieżka do dostawcy, który będzie używany podczas uruchamiania testów przeglądarkowych. Vitest udostępnia dwóch dostawców: webdriverio (domyślnie) i playwright. Niestandardowi dostawcy powinni być eksportowani za pomocą eksportu default i mieć następujący kształt:

export interface BrowserProvider {
  name: string;
  getSupportedBrowsers(): readonly string[];
  initialize(ctx: Vitest, options: { browser: string }): Awaitable<void>;
  openPage(url: string): Awaitable<void>;
  close(): Awaitable<void>;
}

WARNING

To jest zaawansowane API dla autorów bibliotek. Jeśli potrzebujesz tylko uruchomić testy w przeglądarce, użyj opcji browser.

browser.slowHijackESM

Typ: boolean
Domyślnie: true
Wersja: Od Vitest 0.31.0

Podczas uruchamiania testów w Node.js, Vitest może używać własnego mechanizmu rozpoznawania modułów, aby ułatwić mockowanie modułów za pomocą składni vi.mock. Jednak odtworzenie mechanizmu rozpoznawania modułów ES w przeglądarce nie jest proste, dlatego musimy przekształcić pliki źródłowe, zanim przeglądarka będzie mogła z nich korzystać.

Ta opcja nie ma wpływu na testy uruchamiane w Node.js.

Ta opcja jest domyślnie włączona podczas uruchamiania w przeglądarce. Jeśli nie korzystasz z szpiegowania modułów ES za pomocą vi.spyOn i nie używasz vi.mock, możesz wyłączyć tę opcję, aby nieznacznie poprawić wydajność.

clearMocks

Typ: boolean
Domyślnie: false

Wywołuje .mockClear() na wszystkich szpiegach przed każdym testem. Powoduje to wyczyszczenie historii mocków, ale nie resetuje ich implementacji do domyślnej.

mockReset

Typ: boolean
Domyślnie: false

Wywołuje .mockReset() na wszystkich szpiegach przed każdym testem. Powoduje to wyczyszczenie historii mocków i zresetowanie ich implementacji do pustej funkcji, która zwraca undefined.

restoreMocks

Typ: boolean
Domyślnie: false

Wywołuje .mockRestore() na wszystkich szpiegach przed każdym testem. Powoduje to wyczyszczenie historii mocków i zresetowanie ich implementacji do oryginalnej implementacji.

unstubEnvs

Typ: boolean
Domyślnie: false
Wersja: Od Vitest 0.26.0

Wywołuje vi.unstubAllEnvs przed każdym testem.

unstubGlobals

Typ: boolean
Domyślnie: false
Wersja: Od Vitest 0.26.0

Wywołuje vi.unstubAllGlobals przed każdym testem.

testTransformMode

Typ: { web?, ssr? }
Wersja: Od Vitest 0.34.0

Określa metodę transformacji dla modułów importowanych wewnątrz testu, które pasują do wzorca glob. Domyślnie zależy od środowiska. Na przykład, testy ze środowiskiem JSDOM przetworzą wszystkie pliki z flagą ssr: false, a testy ze środowiskiem Node przetworzą wszystkie moduły z flagą ssr: true.

testTransformMode.ssr

Typ: string[]
Domyślnie: []

Dla modułów wewnątrz określonych testów używany jest potok transformacji SSR (Server-Side Rendering).
Wtyczki Vite otrzymają flagę ssr: true podczas przetwarzania tych plików.

testTransformMode.web

Typ: string[]
Domyślnie: []

Najpierw wykonywana jest normalna transformacja przeznaczona dla przeglądarki, a następnie przepisywanie SSR, aby uruchomić kod w Node.
Wtyczki Vite otrzymają flagę ssr: false podczas przetwarzania tych plików.

snapshotFormat*

Typ: PrettyFormatOptions

Opcje formatowania dla testowania migawkowego (snapshot testing). Te opcje są przekazywane do pretty-format.

resolveSnapshotPath*

Typ: (testPath: string, snapExtension: string) => string
Domyślnie: przechowuje pliki migawek w katalogu __snapshots__

Zastępuje domyślną ścieżkę zapisu migawek. Na przykład, aby przechowywać migawki obok plików testowych:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    resolveSnapshotPath: (testPath, snapExtension) => testPath + snapExtension,
  },
});

allowOnly

Typ: boolean
Domyślnie: false
CLI: --allowOnly, --allowOnly=false

Umożliwia uruchamianie tylko testów i zestawów testów oznaczonych jako "only".

dangerouslyIgnoreUnhandledErrors*

Typ: boolean
Domyślnie: false
CLI: --dangerouslyIgnoreUnhandledErrors --dangerouslyIgnoreUnhandledErrors=false

Ignoruje wszystkie nieobsłużone błędy, które wystąpią.

passWithNoTests*

Typ: boolean
Domyślnie: false
CLI: --passWithNoTests, --passWithNoTests=false

Vitest nie zakończy się niepowodzeniem, jeśli nie zostaną znalezione żadne testy.

logHeapUsage

Typ: boolean
Domyślnie: false
CLI: --logHeapUsage, --logHeapUsage=false

Wyświetla użycie sterty po każdym teście. Przydatne do debugowania wycieków pamięci.

css

Typ: boolean | { include?, exclude?, modules? }

Konfiguruje, czy CSS powinien być przetwarzany. Gdy jest wykluczony, pliki CSS zostaną zastąpione pustymi ciągami znaków, aby pominąć dalsze przetwarzanie. Moduły CSS zwrócą proxy, aby nie wpływać na działanie aplikacji.

css.include

Typ: RegExp | RegExp[]
Domyślnie: []

Wzorzec wyrażenia regularnego dla plików, które mają zwracać rzeczywisty CSS i będą przetwarzane przez potok Vite.

TIP

Aby przetworzyć wszystkie pliki CSS, użyj /.+/.

css.exclude

Typ: RegExp | RegExp[]
Domyślnie: []

Wzorzec wyrażenia regularnego dla plików, które zwrócą pusty plik CSS.

css.modules

Typ: { classNameStrategy? }
Domyślnie: {}

css.modules.classNameStrategy

Typ: 'stable' | 'scoped' | 'non-scoped'
Domyślnie: 'stable'

Jeśli zdecydujesz się przetwarzać pliki CSS, możesz skonfigurować, czy nazwy klas w modułach CSS powinny być objęte zakresem (scoped). Możesz wybrać jedną z opcji:

stable: nazwy klas będą generowane jako _${name}_${hashedFilename}, co oznacza, że wygenerowana klasa pozostanie taka sama, jeśli zawartość CSS zostanie zmieniona, ale zmieni się, jeśli nazwa pliku zostanie zmodyfikowana lub plik zostanie przeniesiony do innego folderu. To ustawienie jest przydatne, jeśli używasz funkcji migawek.
scoped: nazwy klas będą generowane jak zwykle, z uwzględnieniem metody css.modules.generateScopeName, jeśli ją masz i przetwarzanie CSS jest włączone. Domyślnie nazwa pliku będzie generowana jako _${name}_${hash}, gdzie hash zawiera nazwę pliku i zawartość pliku.
non-scoped: nazwy klas nie będą haszowane.

WARNING

Domyślnie Vitest używa proxy, omijając przetwarzanie modułów CSS. Jeśli polegasz na właściwościach CSS w swoich klasach, musisz włączyć przetwarzanie CSS za pomocą opcji include.

maxConcurrency

Typ: number
Domyślnie: 5

Liczba testów oznaczonych jako test.concurrent, które mogą być uruchamiane jednocześnie.

Testy przekraczające ten limit zostaną umieszczone w kolejce i uruchomione, gdy zwolni się zasób.

cache*

Typ: false | { dir? }

Opcje konfigurowania polityki cache Vitest. Obecnie Vitest przechowuje cache dla wyników testów, aby najpierw uruchamiać dłuższe i nieudane testy.

cache.dir

Typ: string
Domyślnie: node_modules/.vitest

Ścieżka do katalogu cache.

sequence

Typ: { sequencer?, shuffle?, seed?, hooks?, setupFiles? }

Opcje dotyczące sposobu sortowania testów.

Możesz podać opcje sekwencji do CLI za pomocą notacji kropkowej:

npx vitest --sequence.shuffle --sequence.seed=1000

sequence.sequencer*

Typ: TestSequencerConstructor
Domyślnie: BaseSequencer

Niestandardowa klasa, która definiuje metody fragmentowania i sortowania. Możesz rozszerzyć BaseSequencer z vitest/node, jeśli potrzebujesz tylko przedefiniować jedną z metod sort i shard, ale obie powinny istnieć.

Fragmentowanie odbywa się przed sortowaniem i tylko wtedy, gdy podano opcję --shard.

sequence.shuffle

Typ: boolean
Domyślnie: false
CLI: --sequence.shuffle, --sequence.shuffle=false

Jeśli chcesz, aby testy były uruchamiane losowo, możesz włączyć to za pomocą tej opcji lub argumentu CLI --sequence.shuffle.

Vitest zazwyczaj używa pamięci podręcznej (cache) do sortowania testów, dzięki czemu długotrwałe testy rozpoczynają się wcześniej, co przyspiesza ich uruchamianie. Uruchamianie testów w losowej kolejności spowoduje utratę tej poprawy wydajności, ale może być przydatne do wykrywania testów, które nieumyślnie zależą od wcześniejszych uruchomień.

sequence.concurrent

Typ: boolean
Domyślnie: false
CLI: --sequence.concurrent, --sequence.concurrent=false
Wersja: Od Vitest 0.32.2

Jeśli chcesz, aby testy były uruchamiane współbieżnie, możesz włączyć to za pomocą tej opcji lub argumentu CLI --sequence.concurrent.

sequence.seed*

Typ: number
Domyślnie: Date.now()
CLI: --sequence.seed=1000

Ustawia ziarno losowości, jeśli testy są uruchamiane w losowej kolejności.

sequence.hooks

Typ: 'stack' | 'list' | 'parallel'
Domyślnie: 'parallel'
CLI: --sequence.hooks=<value>

Zmienia kolejność wykonywania hooków.

stack ustawi kolejność funkcji "after" w odwrotnej kolejności, funkcje "before" zostaną uruchomione w kolejności, w jakiej zostały zdefiniowane
list ustawi kolejność wszystkich hooków w kolejności, w jakiej zostały zdefiniowane
parallel uruchomi hooki w jednej grupie równolegle (hooki w nadrzędnych zestawach testów nadal będą uruchamiane przed hookami bieżącego zestawu testów)

sequence.setupFiles

Typ: 'list' | 'parallel'
Domyślnie: 'parallel'
CLI: --sequence.setupFiles=<value>
Wersja: Od Vitest 0.29.3

Zmienia kolejność wykonywania plików konfiguracyjnych (setup files).

list uruchomi pliki konfiguracyjne w kolejności, w jakiej zostały zdefiniowane
parallel uruchomi pliki konfiguracyjne równolegle

typecheck

Opcje konfigurowania środowiska testowego weryfikacji typów.

typecheck.checker

Typ: 'tsc' | 'vue-tsc' | string
Domyślnie: tsc

Jakie narzędzie ma być używane do sprawdzania typów. Vitest uruchamia proces z określonymi parametrami dla łatwiejszego parsowania, w zależności od typu. Checker powinien implementować ten sam format wyjściowy co tsc.

Musisz mieć zainstalowany pakiet, aby użyć typecheckera:

tsc wymaga pakietu typescript
vue-tsc wymaga pakietu vue-tsc

Możesz również przekazać ścieżkę do niestandardowego pliku binarnego lub nazwę polecenia, które generuje takie samo wyjście jak tsc --noEmit --pretty false.

typecheck.include

Typ: string[]
Domyślnie: ['**/*.{test,spec}-d.?(c|m)[jt]s?(x)']

Wzorzec glob dla plików, które powinny być traktowane jako pliki testowe.

typecheck.exclude

Typ: string[]
Domyślnie: ['**/node_modules/**', '**/dist/**', '**/cypress/**', '**/.{idea,git,cache,output,temp}/**']

Wzorzec glob dla plików, które nie powinny być traktowane jako pliki testowe.

typecheck.allowJs

Typ: boolean
Domyślnie: false

Sprawdź pliki JS, które mają komentarz @ts-check. Jeśli masz to włączone w tsconfig, to to nie zostanie nadpisane.

typecheck.ignoreSourceErrors

Typ: boolean
Domyślnie: false

Nie przerywaj działania, jeśli Vitest znajdzie błędy poza plikami testowymi. To w ogóle nie pokaże błędów spoza testów.

Domyślnie, jeśli Vitest znajdzie błąd w kodzie źródłowym, zakończy zestaw testów niepowodzeniem.

typecheck.tsconfig

Typ: string
Domyślnie: próbuje znaleźć najbliższy tsconfig.json

Ścieżka do niestandardowego tsconfig, względna do katalogu głównego projektu.

slowTestThreshold*

Typ: number
Domyślnie: 300

Liczba milisekund, po której test jest uważany za wolny i oznaczany jako wolny w wynikach.

chaiConfig

Typ: { includeStack?, showDiff?, truncateThreshold? }
Domyślnie: { includeStack: false, showDiff: true, truncateThreshold: 40 }
Wersja: Od Vitest 0.30.0

Odpowiednik konfiguracji Chai.

chaiConfig.includeStack

Typ: boolean
Domyślnie: false

Wpływa na to, czy ślad stosu jest dołączany do komunikatu o błędzie asercji. Domyślna wartość false pomija ślad stosu w komunikacie o błędzie.

chaiConfig.showDiff

Typ: boolean
Domyślnie: true

Określa, czy flaga showDiff powinna być dołączona do zgłaszanych błędów AssertionErrors. false zawsze będzie false; true będzie true, gdy asercja zażądała wyświetlenia różnicy.

chaiConfig.truncateThreshold

Typ: number
Domyślnie: 40

Ustawia próg długości dla rzeczywistych i oczekiwanych wartości w błędach asercji. Jeśli ten próg zostanie przekroczony, na przykład dla dużych struktur danych, wartość zostanie zastąpiona czymś w rodzaju [ Array(3) ] lub { Object (prop1, prop2) }. Ustaw na 0, jeśli chcesz całkowicie wyłączyć przycinanie.

Ta opcja konfiguracyjna wpływa na przycinanie wartości w tytułach test.each i wewnątrz komunikatu o błędzie asercji.

bail

Typ: number
Domyślnie: 0
CLI: --bail=<value>
Wersja: Od Vitest 0.31.0

Przerywa wykonywanie testów, gdy podana liczba testów zakończy się niepowodzeniem.

Domyślnie Vitest uruchomi wszystkie przypadki testowe, nawet jeśli niektóre z nich zakończą się niepowodzeniem. Może to być niepożądane w przypadku procesów CI, w których interesują Cię tylko w 100% udane kompilacje i chcesz zatrzymać wykonywanie testów tak wcześnie, jak to możliwe, gdy wystąpią błędy testów. Opcja bail może być używana do przyspieszenia uruchamiania CI, zapobiegając uruchamianiu większej liczby testów, gdy wystąpiły błędy.

retry

Typ: number
Domyślnie: 0
CLI: --retry=<value>
Wersja: Od Vitest 0.32.3

Ponawia test określoną liczbę razy, jeśli zakończy się niepowodzeniem.

onConsoleLog

Typ: (log: string, type: 'stdout' | 'stderr') => false | void

Niestandardowy handler dla console.log w testach. Jeśli funkcja zwróci false, Vitest nie wypisze logu do konsoli.

Może być przydatny do filtrowania logów z bibliotek zewnętrznych.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    onConsoleLog(log: string, type: 'stdout' | 'stderr'): boolean | void {
      if (log === 'message from third party library' && type === 'stdout')
        return false; // Nie wypisuj logu do konsoli
    },
  },
});

diff

Typ: string
CLI: --diff=<value>
Wersja: Od Vitest 0.34.5

Ścieżka do konfiguracji diff, która będzie używana do generowania interfejsu diff. Przydatne, jeśli chcesz dostosować wyświetlanie różnic.

vitest.diff.tsvitest.config.js

import type { DiffOptions } from 'vitest';
import c from 'picocolors';

export default {
  aIndicator: c.bold('--'),
  bIndicator: c.bold('++'),
  omitAnnotationLines: true,
} satisfies DiffOptions;

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    diff: './vitest.diff.ts',
  },
});

Konfiguracja Vitest ​

Konfiguracja ​

Opcje ​

include ​

exclude ​

includeSource ​

server ​

server.sourcemap ​

server.debug ​

server.debug.dumpModules ​

server.debug.loadDumppedModules ​

server.deps ​

server.deps.external ​

server.deps.inline ​

server.deps.fallbackCJS ​

server.deps.cacheDir ​

deps ​

deps.optimizer ​

deps.optimizer.{mode}.enabled ​

deps.web ​

deps.web.transformAssets ​

deps.web.transformCss ​

deps.web.transformGlobPattern ​

deps.registerNodeLoader* ​

deps.interopDefault ​

deps.moduleDirectories ​

runner ​

benchmark ​

benchmark.include ​

benchmark.exclude ​

benchmark.includeSource ​

benchmark.reporters ​

benchmark.outputFile ​

alias ​

globals ​

environment ​

environmentOptions ​

environmentMatchGlobs ​

poolMatchGlobs ​

update* ​

watch* ​

root ​

reporters* ​

outputFile* ​

experimentalVmThreads ​

experimentalVmWorkerMemoryLimit ​

threads ​

singleThread ​

maxThreads* ​

minThreads* ​

useAtomics* ​

testTimeout ​

hookTimeout ​

teardownTimeout* ​

silent* ​

setupFiles ​

globalSetup ​

watchExclude* ​

forceRerunTriggers* ​

isolate ​

coverage* ​

coverage.provider ​

coverage.enabled ​

coverage.include ​

coverage.extension ​

coverage.exclude ​

coverage.all ​

coverage.clean ​

coverage.cleanOnRerun ​

coverage.reportsDirectory ​

coverage.reporter ​

coverage.reportOnFailure ​

coverage.allowExternal ​

coverage.skipFull ​

coverage.perFile ​

coverage.thresholdAutoUpdate ​

coverage.lines ​

coverage.functions ​

coverage.branches ​

coverage.statements ​

Konfiguracja Vitest

Konfiguracja

Opcje

include

exclude

includeSource

server

server.sourcemap

server.debug

server.debug.dumpModules

server.debug.loadDumppedModules

server.deps

server.deps.external

server.deps.inline

server.deps.fallbackCJS

server.deps.cacheDir

deps

deps.optimizer

deps.optimizer.{mode}.enabled

deps.web

deps.web.transformAssets

deps.web.transformCss

deps.web.transformGlobPattern

deps.registerNodeLoader*

deps.interopDefault

deps.moduleDirectories

runner

benchmark

benchmark.include

benchmark.exclude

benchmark.includeSource

benchmark.reporters

benchmark.outputFile

alias

globals

environment

environmentOptions

environmentMatchGlobs

poolMatchGlobs

update*

watch*

root

reporters*

outputFile*

experimentalVmThreads

experimentalVmWorkerMemoryLimit

threads

singleThread

maxThreads*

minThreads*

useAtomics*

testTimeout

hookTimeout

teardownTimeout*

silent*

setupFiles

globalSetup

watchExclude*

forceRerunTriggers*

isolate

coverage*

coverage.provider

coverage.enabled

coverage.include

coverage.extension

coverage.exclude

coverage.all

coverage.clean

coverage.cleanOnRerun

coverage.reportsDirectory

coverage.reporter

coverage.reportOnFailure

coverage.allowExternal

coverage.skipFull

coverage.perFile

coverage.thresholdAutoUpdate

coverage.lines

coverage.functions

coverage.branches

coverage.statements