Konfiguracja Vitest

Jeśli używasz Vite i posiadasz plik vite.config, Vitest automatycznie go odczyta, aby dopasować wtyczki i konfigurację Twojej aplikacji Vite. Jeśli potrzebujesz innej konfiguracji dla testów lub Twoja główna aplikacja nie jest ściśle związana z Vite, możesz:

Utworzyć plik vitest.config.ts, który będzie miał wyższy priorytet, nadpisując konfigurację z vite.config.ts (Vitest obsługuje wszystkie standardowe rozszerzenia JS i TS, ale nie json). Oznacza to, że wszystkie opcje z Twojego vite.config zostaną zignorowane.
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 (zostanie ustawiona na test/benchmark, jeśli nie zostanie nadpisana za pomocą --mode), aby warunkowo zastosować inną konfigurację w vite.config.ts.

Aby skonfigurować vitest, dodaj właściwość test do swojej konfiguracji Vite. Będziesz również musiał dodać odwołanie do typów Vitest za pomocą triple slash command na początku pliku konfiguracyjnego, jeśli importujesz defineConfig bezpośrednio z vite.

Otwórz przykłady konfiguracji

Używając defineConfig z vite, postępuj w następujący sposób:

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

export default defineConfig({
  test: {
    // ... Określ opcje tutaj.
  },
});

<reference types="vitest" /> przestanie działać w Vitest 4, ale już teraz możesz rozpocząć migrację do vitest/config:

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

export default defineConfig({
  test: {
    // ... Określ opcje tutaj.
  },
});

Używając defineConfig z vitest/config, postępuj w ten sposób:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    // ... Określ opcje tutaj.
  },
});

Możesz pobrać domyślne opcje Vitest, aby je rozszerzyć w razie potrzeby:

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

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

Używając oddzielnego vitest.config.js, możesz również rozszerzyć opcje Vite z innego pliku konfiguracyjnego, jeśli to konieczne:

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

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

Jeśli Twoja konfiguracja Vite jest zdefiniowana jako funkcja, możesz zdefiniować konfigurację 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/*'],
      },
    })
  )
);

WARNING

Wszystkie wymienione opcje na tej stronie znajdują się w konfiguracji, wewnątrz właściwości test:

export default defineConfig({
  test: {
    exclude: [],
  },
});

Ponieważ Vitest używa konfiguracji Vite, możesz również użyć dowolnej opcji konfiguracyjnej z Vite. Na przykład, define do definiowania zmiennych globalnych lub resolve.alias do definiowania aliasów – te opcje powinny być zdefiniowane bezpośrednio w konfiguracji, nie wewnątrz właściwości test.

Opcje konfiguracyjne, które nie są obsługiwane w konfiguracji projektu, są oznaczone znakiem *. Oznacza to, że mogą być ustawione tylko w głównej konfiguracji Vitest.

include

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

Lista wzorców glob, które pasują do Twoich plików testowych.

UWAGA

Podczas korzystania z pokrycia kodu, Vitest automatycznie dodaje wzorce include plików testowych do domyślnych wzorców exclude pokrycia. Zobacz coverage.exclude.

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,eslint,prettier}.config.*']
CLI: vitest --exclude "**/excluded-file"

Lista wzorców glob, które powinny być wykluczone z Twoich plików testowych.

WARNING

Ta opcja nie wpływa na pokrycie kodu. Jeśli chcesz usunąć niektóre pliki z raportu pokrycia, użyj coverage.exclude.

Jest to jedyna opcja, która nie nadpisuje konfiguracji, jeśli zostanie podana z flagą CLI. Wszystkie wzorce glob dodane za pomocą flagi --exclude zostaną dodane do opcji exclude w konfiguracji.

includeSource

Typ: string[]
Domyślnie: []

Wzorce glob dla plików testowych umieszczonych w kodzie źródłowym.

Gdy zdefiniowane, Vitest uruchomi wszystkie pasujące pliki zawierające import.meta.vitest.

name

Typ: string | { label: string, color?: LabelColor }

Przypisz niestandardową nazwę do projektu testowego lub procesu Vitest. Nazwa będzie widoczna w CLI i UI, a także dostępna w API Node.js poprzez project.name.

Kolor używany przez CLI i UI można zmienić, podając obiekt z właściwością color.

server

Typ: { sourcemap?, deps?, ... }

Opcje serwera Vite-Node.

server.sourcemap

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

Wstrzyknij wbudowaną mapę źródłową do modułów.

server.debug

Typ: { dumpModules?, loadDumppedModules? }

Opcje debuggera Vite-Node.

server.debug.dumpModules

Typ: boolean | string

Zrzuca przekształcony moduł do systemu plików. Podanie ciągu znaków spowoduje zrzucenie do określonej ścieżki.

server.debug.loadDumppedModules

Typ: boolean

Odczytuje zrzucony moduł z systemu plików, jeśli istnieje. Przydatne do debugowania poprzez modyfikację wyniku zrzutu z systemu plików.

server.deps

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

Obsługa rozwiązywania zależności.

server.deps.external

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

Externalizacja oznacza, że Vite przekaże pakiet bezpośrednio do natywnego środowiska Node.js. Zewnętrzne zależności nie będą podlegać transformatorom i resolverom Vite, więc nie obsługują HMR przy ponownym ładowaniu. Domyślnie wszystkie pakiety w node_modules są externalizowane.

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

Jeśli użyto wyrażenia regularnego, 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 wbudowane. Może to być pomocne w obsłudze pakietów, które dostarczają .js w formacie ESM (którego Node nie może obsłużyć).

Jeśli 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 spowodować pewne niezgodności, jeśli pakiet ma inną logikę w trybie ESM i CJS.

server.deps.cacheDir

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

Katalog do zapisywania plików pamięci podręcznej.

deps

Typ: { optimizer?, ... }

Obsługa rozwiązywania zależności.

deps.optimizer

Typ: { ssr?, web? }
Zobacz także: Opcje optymalizacji zależności

Włącz optymalizację zależności. Jeśli masz dużo testów, może to poprawić ich wydajność.

Gdy Vitest napotka zewnętrzną bibliotekę wymienioną w include, zostanie ona spakowana w jeden plik za pomocą esbuild i zaimportowana jako cały moduł. Jest to korzystne z kilku powodów:

Importowanie pakietów z dużą ilością importów jest kosztowne. Pakując je w jeden plik, możemy zaoszczędzić dużo czasu.
Importowanie bibliotek UI jest kosztowne, ponieważ nie są one przeznaczone do uruchamiania w Node.js.
Twoja konfiguracja alias jest teraz respektowana w spakowanych pakietach.
Kod w Twoich testach działa bliżej tego, jak działa w przeglądarce.

Pamiętaj, że tylko pakiety w opcji deps.optimizer?.[mode].include są pakowane (niektóre wtyczki automatycznie to wypełniają, np. 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, oraz optimizer.ssr dla środowisk node i edge, ale jest to konfigurowalne za pomocą transformMode.

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

TIP

Nie będziesz mógł edytować kodu node_modules w celu debugowania, ponieważ kod faktycznie 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: false

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

deps.web

Typ: { transformAssets?, ... }

Opcje, które są stosowane do plików zewnętrznych, 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 w 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

Czy Vitest powinien przetwarzać pliki zasobów (.png, .svg, .jpg itp.) i rozwiązywać je tak, jak Vite robi to w przeglądarce.

Ten moduł będzie miał domyślny eksport równy ścieżce do zasobu, jeśli nie określono żadnego zapytania.

WARNING

Obecnie ta opcja działa tylko z pulami vmThreads i vmForks.

deps.web.transformCss

Typ: boolean
Domyślnie: true

Czy Vitest powinien przetwarzać pliki CSS (.css, .scss, .sass itp.) i rozwiązywać je tak, jak Vite robi to 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 pulami vmThreads i vmForks.

deps.web.transformGlobPattern

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

Wzorzec wyrażenia regularnego do dopasowywania plików zewnętrznych, które powinny zostać przekształcone.

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

WARNING

Obecnie ta opcja działa tylko z pulami vmThreads i vmForks.

deps.interopDefault

Typ: boolean
Domyślnie: true

Interpretuj domyślny eksport modułu CJS jako eksporty nazwane. Niektóre zależności pakują tylko moduły CJS i nie używają eksportów nazwanych, 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ą eksportów nazwanych, 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 wykonuje analizy statycznej i nie może zgłosić błędu przed uruchomieniem kodu, więc najprawdopodobniej zobaczysz ten błąd podczas uruchamiania testów, jeśli ta funkcja jest wyłączona:

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

Domyślnie Vitest zakłada, że używasz bundlera, aby to ominąć i nie zgłosi błędu, ale możesz ręcznie wyłączyć to zachowanie, 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 zachowanie 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 katalogu głównym projektu.

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

Ustawienie tej opcji nadpisze domyślne. Jeśli chcesz nadal przeszukiwać node_modules w poszukiwaniu pakietów, uwzględnij ją 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

Ścieżka do niestandardowego runnera testów. Jest to zaawansowana funkcja i powinna być używana z niestandardowymi runnerami bibliotek. Możesz przeczytać więcej na ten temat 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 do uwzględnienia plików testów porównawczych.

benchmark.exclude

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

Wzorce glob do wykluczenia plików testów porównawczych.

benchmark.includeSource

Typ: string[]
Domyślnie: []

Wzorce glob dla plików testów porównawczych umieszczonych w kodzie źródłowym. Ta opcja jest podobna do includeSource.

Gdy zdefiniowane, Vitest uruchomi wszystkie pasujące pliki zawierające import.meta.vitest.

benchmark.reporters

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

Niestandardowy raporter dla wyjścia. Może zawierać jedną lub więcej wbudowanych nazw raportów, instancji raporterów i/lub ścieżek do niestandardowych raporterów.

benchmark.outputFile

Przestarzałe na rzecz benchmark.outputJson.

benchmark.outputJson

Typ: string | undefined
Domyślnie: undefined

Ścieżka pliku do przechowywania wyniku testu porównawczego, który może być później użyty do opcji --compare.

Na przykład:

# zapisz wynik gałęzi głównej
git checkout main
vitest bench --outputJson main.json

# zmień gałąź i porównaj z główną
git checkout feature
vitest bench --compare main.json

benchmark.compare

Typ: string | undefined
Domyślnie: undefined

Ścieżka pliku do poprzedniego wyniku testu porównawczego, z którym należy porównać bieżące uruchomienia.

alias

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

Zdefiniuj niestandardowe aliasy podczas uruchamiania w testach. Zostaną one połączone z aliasami z resolve.alias.

WARNING

Vitest używa prymitywów Vite SSR do uruchamiania testów, co ma pewne pułapki.

Aliasy wpływają tylko na moduły importowane bezpośrednio za pomocą słowa kluczowego import przez moduł wbudowany (cały kod źródłowy jest domyślnie wbudowany).
Vitest nie obsługuje aliasowania wywołań require.
Jeśli aliasujesz zewnętrzną zależność (np. react -> preact), możesz chcieć aliasować rzeczywiste pakiety node_modules, aby działało to dla zależności zewnętrznych. Zarówno Yarn, jak i pnpm obsługują aliasowanie za pomocą prefiksu npm:.

globals

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

Domyślnie vitest nie udostępnia globalnych API, aby zachować jawność. Jeśli wolisz używać API globalnie, tak jak Jest, możesz przekazać opcję --globals do CLI lub dodać globals: true w konfiguracji.

import { defineConfig } from 'vitest/config';

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

Aby TypeScript działał z globalnymi API, dodaj vitest/globals do pola types w pliku tsconfig.json.

json

{
  "compilerOptions": {
    "types": ["vitest/globals"]
  }
}

Jeśli zredefiniowałeś swoje typeRoots, aby uwzględnić więcej typów w kompilacji, będziesz musiał dodać z powrotem node_modules, aby vitest/globals było wykrywalne.

json

{
  "compilerOptions": {
    "typeRoots": ["./types", "./node_modules/@types", "./node_modules"],
    "types": ["vitest/globals"]
  }
}

Jeśli już używasz unplugin-auto-import w swoim projekcie, możesz go również użyć bezpośrednio do automatycznego importowania tych API.

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>

Środowisko, które zostanie użyte do testowania. Domyślnym środowiskiem w Vitest jest środowisko Node.js. Jeśli budujesz aplikację webową, możesz użyć środowiska podobnego do przeglądarki za pośrednictwem jsdom lub happy-dom.

Jeśli budujesz funkcje brzegowe, możesz użyć środowiska edge-runtime.

TIP

Możesz również użyć trybu przeglądarki, aby uruchamiać testy integracyjne lub jednostkowe w przeglądarce bez mockowania środowiska.

Dodając docblock @vitest-environment lub komentarz na początku pliku, możesz określić inne środowisko, które ma być używane dla wszystkich testów w tym pliku:

Styl docblock:

/**
 * @vitest-environment jsdom
 */

test('use jsdom in this test file', () => {
  const element = document.createElement('div');
  expect(element).not.toBeNull();
});

Styl komentarza:

// @vitest-environment happy-dom

test('use happy-dom in this test file', () => {
  const element = document.createElement('div');
  expect(element).not.toBeNull();
});

Dla kompatybilności z Jest, istnieje również @jest-environment:

/**
 * @jest-environment jsdom
 */

test('use jsdom in this test file', () => {
  const element = document.createElement('div');
  expect(element).not.toBeNull();
});

Jeśli uruchamiasz Vitest z flagą --isolate=false, Twoje testy zostaną uruchomione w następującej kolejności: node, jsdom, happy-dom, edge-runtime, niestandardowe środowiska. Oznacza to, że każdy test z tym samym środowiskiem jest grupowany, ale nadal działa sekwencyjnie.

Począwszy od wersji 0.23.0, możesz również zdefiniować niestandardowe środowisko. Gdy używane jest środowisko inne niż wbudowane, Vitest spróbuje załadować pakiet vitest-environment-${name}. Ten pakiet powinien eksportować obiekt o kształcie Environment:

import type { Environment } from 'vitest';

export default <Environment>{
  name: 'custom',
  transformMode: 'ssr',
  setup() {
    // niestandardowa konfiguracja
    return {
      teardown() {
        // wywoływane po uruchomieniu wszystkich testów z tym środowiskiem
      },
    };
  },
};

Vitest udostępnia również builtinEnvironments poprzez wpis vitest/environments, na wypadek gdybyś chciał go tylko rozszerzyć. Możesz przeczytać więcej o rozszerzaniu środowisk w naszym przewodniku.

TIP

Środowisko jsdom udostępnia globalną zmienną jsdom równą bieżącej instancji JSDOM. Jeśli chcesz, aby TypeScript ją rozpoznawał, możesz dodać vitest/jsdom do swojego tsconfig.json, gdy używasz tego środowiska:

json

{
  "compilerOptions": {
    "types": ["vitest/jsdom"]
  }
}

environmentOptions

Typ: Record<'jsdom' | string, unknown>
Domyślnie: {}

Te opcje są przekazywane do metody setup bieżącego environment. Domyślnie możesz skonfigurować tylko opcje JSDOM, jeśli używasz go jako środowiska testowego.

environmentMatchGlobs

Typ: [string, EnvironmentName][]
Domyślnie: []

PRZESTARZAŁE

To API zostało przestarzałe w Vitest 3. Zamiast tego użyj projektów, aby zdefiniować różne konfiguracje.

export default defineConfig({
  test: {
    environmentMatchGlobs: [ 
      ['./*.jsdom.test.ts', 'jsdom'], 
    ], 
    projects: [ 
      { 
        extends: true, 
        test: { 
          environment: 'jsdom', 
        }, 
      }, 
    ], 
  },
})

Automatycznie przypisuj środowisko na podstawie wzorców glob. Użyte zostanie pierwsze dopasowanie.

Na przykład:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    environmentMatchGlobs: [
      // wszystkie testy w 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' | 'forks' | 'vmThreads' | 'vmForks' | 'typescript'][]
Domyślnie: []

PRZESTARZAŁE

To API zostało przestarzałe w Vitest 3. Zamiast tego użyj projektów, aby zdefiniować różne konfiguracje:

export default defineConfig({
  test: {
    poolMatchGlobs: [ 
      ['./*.threads.test.ts', 'threads'], 
    ], 
    projects: [ 
      { 
        test: { 
          extends: true, 
          pool: 'threads', 
        }, 
      }, 
    ], 
  },
})

Automatycznie przypisuj pulę, w której testy będą uruchamiane, na podstawie wzorców glob. Użyte zostanie pierwsze dopasowanie.

Na przykład:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolMatchGlobs: [
      // wszystkie testy w katalogu "worker-specific" będą uruchamiane w workerze, tak jakbyś włączył dla nich `--pool=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śliłeś innych wzorców glob
      // ...
    ],
  },
});

update*

Typ: boolean
Domyślnie: false
CLI: -u, --update, --update=false

Aktualizuj pliki migawek. Spowoduje to aktualizację wszystkich zmienionych migawek i usunięcie przestarzałych.

watch*

Typ: boolean
Domyślnie: !process.env.CI && process.stdin.isTTY
CLI: -w, --watch, --watch=false

Włącz tryb obserwacji.

W środowiskach interaktywnych jest to domyślne, chyba że --run jest jawnie określone.

W CI lub gdy uruchamiane z nieinteraktywnej powłoki, tryb "watch" nie jest domyślny, ale można go jawnie włączyć za pomocą tej flagi.

watchTriggerPatterns 3.2.0+ *

Typ: WatcherTriggerPattern[]

Vitest ponownie uruchamia testy na podstawie grafu modułów, który jest wypełniany przez statyczne i dynamiczne instrukcje import. Jednakże, jeśli odczytujesz z systemu plików lub pobierasz z proxy, Vitest nie może wykryć tych zależności.

Aby poprawnie ponownie uruchomić te testy, możesz zdefiniować wzorzec regex i funkcję, która zwraca listę plików testowych do uruchomienia.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    watchTriggerPatterns: [
      {
        pattern: /^src\/(mailers|templates)\/(.*)\.(ts|html|txt)$/,
        testToRun: (id, match) => {
          // względnie do wartości root
          return `./api/tests/mailers/${match[2]}.test.ts`;
        },
      },
    ],
  },
});

WARNING

Zwrócone pliki powinny być bezwzględne lub względne w stosunku do katalogu głównego. Zauważ, że jest to opcja globalna i nie może być używana w konfiguracjach projektu.

root

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

Katalog główny projektu.

dir

Typ: string
CLI: --dir=<path>
Domyślnie: to samo co root

Katalog bazowy do skanowania plików testowych. Możesz określić tę opcję, aby przyspieszyć wykrywanie testów, jeśli Twój katalog główny obejmuje cały projekt.

reporters*

Typ: Reporter | Reporter[]
Domyślnie: 'default'
CLI: --reporter=<name>, --reporter=<name1> --reporter=<name2>

Niestandardowe raportery dla wyjścia. Reporterami mogą być instancje Reportera, ciągiem znaków do wyboru wbudowanych raporterów lub ścieżką do niestandardowej implementacji (np. './path/to/reporter.ts', '@scope/reporter').

outputFile*

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

Zapisz wyniki testów do pliku, gdy opcja --reporter=json, --reporter=html lub --reporter=junit jest również określona. Podając obiekt zamiast ciągu znaków, możesz zdefiniować indywidualne wyjścia podczas używania wielu raporterów.

pool*

Typ: 'threads' | 'forks' | 'vmThreads' | 'vmForks'
Domyślnie: 'forks'
CLI: --pool=threads

Pula używana do uruchamiania testów.

threads*

Włącz wielowątkowość za pomocą tinypool (lekkie rozwidlenie Piscina). Podczas używania wątków nie można używać API związanych z procesami, takich jak process.chdir(). Niektóre biblioteki napisane w językach natywnych, takie jak Prisma, bcrypt i canvas, mają problemy podczas uruchamiania w wielu wątkach i napotykają błędy segmentacji. W takich przypadkach zaleca się użycie puli forks.

forks*

Podobnie jak pula threads, ale używa child_process zamiast worker_threads za pośrednictwem tinypool. Komunikacja między testami a głównym procesem nie jest tak szybka jak w przypadku puli threads. API związane z procesami, takie jak process.chdir(), są dostępne w puli forks.

vmThreads*

Uruchamiaj testy za pomocą kontekstu VM (w środowisku piaskownicy) w puli threads.

To sprawia, że testy działają szybciej, ale moduł VM jest niestabilny podczas uruchamiania kodu ESM. Twoje testy będą wyciekać pamięć - aby temu zaradzić, rozważ ręczną edycję wartości poolOptions.vmThreads.memoryLimit.

WARNING

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

Globalne zmienne w modułach natywnych, takich jak (fs, path itp.), różnią się od globalnych zmiennych 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 błędu w porównaniu do tego używanego w Twoim kodzie:

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

Importowanie modułów ES buforuje je w nieskończoność, co prowadzi do wycieków 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 piaskownicy.

Proszę, bądź świadomy tych problemów podczas korzystania z tej opcji. Zespół Vitest nie może naprawić żadnego z tych problemów po naszej stronie.

vmForks*

Podobnie jak pula vmThreads, ale używa child_process zamiast worker_threads za pośrednictwem tinypool. Komunikacja między testami a głównym procesem nie jest tak szybka jak w przypadku puli vmThreads. API związane z procesami, takie jak process.chdir(), są dostępne w puli vmForks. Należy pamiętać, że ta pula ma te same pułapki wymienione w vmThreads.

poolOptions*

Typ: Record<'threads' | 'forks' | 'vmThreads' | 'vmForks', {}>
Domyślnie: {}

poolOptions.threads

Opcje dla puli threads.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      threads: {
        // Opcje związane z wątkami tutaj
      },
    },
  },
});

poolOptions.threads.maxThreads*

Typ: number | string
Domyślnie: dostępne procesory

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

poolOptions.threads.minThreads*

Typ: number | string
Domyślnie: dostępne procesory

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

poolOptions.threads.singleThread

Typ: boolean
Domyślnie: false

Uruchom wszystkie testy z tym samym środowiskiem w jednym wątku roboczym. Spowoduje to wyłączenie wbudowanej izolacji modułów (Twój kod źródłowy lub kod wbudowany nadal będzie ponownie oceniany dla każdego testu), ale może poprawić wydajność testów.

WARNING

Mimo że ta opcja wymusi uruchamianie testów jeden po drugim, różni się ona od --runInBand w Jest. Vitest używa workerów nie tylko do równoległego uruchamiania testów, ale także do zapewnienia izolacji. Wyłączając tę opcję, Twoje testy będą uruchamiane sekwencyjnie, ale w tym samym globalnym kontekście, więc musisz zapewnić izolację samodzielnie.

Może to powodować wszelkiego rodzaju problemy, jeśli polegasz na stanie globalnym (zazwyczaj robią to frameworki frontendowe) lub Twój kod wymaga, aby środowisko było zdefiniowane oddzielnie dla każdego testu. Ale może to znacznie przyspieszyć Twoje testy (do 3 razy szybciej), zwłaszcza te, które niekoniecznie polegają na stanie globalnym lub mogą go łatwo ominąć.

poolOptions.threads.useAtomics*

Typ: boolean
Domyślnie: false

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

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

poolOptions.threads.isolate

Type: boolean
Default: true

Izoluj środowisko każdego pliku testowego.

poolOptions.threads.execArgv*

Typ: string[]
Domyślnie: []

Przekaż dodatkowe argumenty do node w wątkach. Więcej informacji znajdziesz w Command-line API | Node.js.

WARNING

Zachowaj ostrożność podczas używania, ponieważ niektóre opcje mogą spowodować awarię workera, np. --prof, --title. Zobacz https://github.com/nodejs/node/issues/41103.

poolOptions.forks

Opcje dla puli forks.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      forks: {
        // Opcje związane z forkami tutaj
      },
    },
  },
});

poolOptions.forks.maxForks*

Typ: number | string
Domyślnie: dostępne procesory

Maksymalna liczba lub procent forków. Możesz również użyć zmiennej środowiskowej VITEST_MAX_FORKS.

poolOptions.forks.minForks*

Typ: number | string
Domyślnie: dostępne procesory

Minimalna liczba lub procent forków. Możesz również użyć zmiennej środowiskowej VITEST_MIN_FORKS.

poolOptions.forks.isolate

Typ: boolean
Domyślnie: true

Izoluj środowisko dla każdego pliku testowego.

poolOptions.forks.singleFork

Typ: boolean
Domyślnie: false

Uruchom wszystkie testy z tym samym środowiskiem w jednym procesie potomnym. Spowoduje to wyłączenie wbudowanej izolacji modułów (Twój kod źródłowy lub kod wbudowany nadal będzie ponownie oceniany dla każdego testu), ale może poprawić wydajność testów.

WARNING

Mimo że ta opcja wymusi uruchamianie testów jeden po drugim, różni się ona od --runInBand w Jest. Vitest używa procesów potomnych nie tylko do równoległego uruchamiania testów, ale także do zapewnienia izolacji. Wyłączając tę opcję, Twoje testy będą uruchamiane sekwencyjnie, ale w tym samym globalnym kontekście, więc musisz zapewnić izolację samodzielnie.

poolOptions.forks.execArgv*

Typ: string[]
Domyślnie: []

Przekaż dodatkowe argumenty do procesu node w procesach potomnych. Więcej informacji znajdziesz w Command-line API | Node.js.

WARNING

Zachowaj ostrożność podczas używania, ponieważ niektóre opcje mogą spowodować awarię workera, np. --prof, --title. Zobacz https://github.com/nodejs/node/issues/41103.

poolOptions.vmThreads

Opcje dla puli vmThreads.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      vmThreads: {
        // Opcje związane z wątkami VM tutaj
      },
    },
  },
});

poolOptions.vmThreads.maxThreads*

Typ: number | string
Domyślnie: dostępne procesory

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

poolOptions.vmThreads.minThreads*

Typ: number | string
Domyślnie: dostępne procesory

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

poolOptions.vmThreads.memoryLimit*

Typ: string | number
Domyślnie: 1 / CPU Cores

Określa limit pamięci dla workerów przed ich recyklingiem. Ta wartość w dużym stopniu zależy od Twojego środowiska, dlatego lepiej określić ją ręcznie, zamiast polegać na wartości domyślnej.

TIP

Implementacja opiera się na workerIdleMemoryLimit z Jest.

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

<= 1 - Wartość jest traktowana jako procent pamięci systemowej. Tak więc 0.5 ustawia limit pamięci workera na połowę całkowitej pamięci systemowej.
\> 1 - Traktowane jako stała wartość bajtowa. Ze względu na poprzednią regułę, jeśli chciałbyś wartość 1 bajta (nie wiem dlaczego), mógłbyś 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łowego zgłaszania pamięci systemowej.

poolOptions.vmThreads.useAtomics*

Typ: boolean
Domyślnie: false

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

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

poolOptions.vmThreads.execArgv*

Typ: string[]
Domyślnie: []

Przekaż dodatkowe argumenty do procesu node w kontekście VM. Więcej informacji znajdziesz w Command-line API | Node.js.

WARNING

Zachowaj ostrożność podczas używania, ponieważ niektóre opcje mogą spowodować awarię workera, np. --prof, --title. Zobacz https://github.com/nodejs/node/issues/41103.

poolOptions.vmForks*

Opcje dla puli vmForks.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      vmForks: {
        // Opcje związane z forkami VM tutaj
      },
    },
  },
});

poolOptions.vmForks.maxForks*

Typ: number | string
Domyślnie: dostępne procesory

Maksymalna liczba lub procent forków. Możesz również użyć zmiennej środowiskowej VITEST_MAX_FORKS.

poolOptions.vmForks.minForks*

Typ: number | string
Domyślnie: dostępne procesory

Minimalna liczba lub procent forków. Możesz również użyć zmiennej środowiskowej VITEST_MIN_FORKS.

poolOptions.vmForks.memoryLimit*

Typ: string | number
Domyślnie: 1 / CPU Cores

poolOptions.vmForks.execArgv*

Typ: string[]
Domyślnie: []

Przekaż dodatkowe argumenty do procesu node w kontekście VM. Więcej informacji znajdziesz w Command-line API | Node.js.

WARNING

Zachowaj ostrożność podczas używania, ponieważ niektóre opcje mogą spowodować awarię workera, np. --prof, --title. Zobacz https://github.com/nodejs/node/issues/41103.

fileParallelism*

Typ: boolean
Domyślnie: true
CLI: --no-file-parallelism, --fileParallelism=false

Czy wszystkie pliki testowe powinny być uruchamiane równolegle. Ustawienie tej opcji na false nadpisze opcje maxWorkers i minWorkers na 1.

TIP

Ta opcja nie wpływa na testy uruchamiane w tym samym pliku. Jeśli chcesz uruchomić je równolegle, użyj opcji concurrent w describe lub za pośrednictwem konfiguracji.

maxWorkers*

Typ: number | string

Maksymalna liczba lub procent workerów do uruchamiania testów. poolOptions.{threads,vmThreads}.maxThreads/poolOptions.forks.maxForks ma wyższy priorytet.

minWorkers*

Typ: number | string

Minimalna liczba lub procent workerów do uruchamiania testów. poolOptions.{threads,vmThreads}.minThreads/poolOptions.forks.minForks ma wyższy priorytet.

testTimeout

Typ: number
Domyślnie: 5_000 w Node.js, 15_000 jeśli browser.enabled jest true
CLI: --test-timeout=5000, --testTimeout=5000

Domyślny limit czasu testu w milisekundach. Użyj 0, aby całkowicie wyłączyć limit czasu.

hookTimeout

Typ: number
Domyślnie: 10_000 w Node.js, 30_000 jeśli browser.enabled jest true
CLI: --hook-timeout=10000, --hookTimeout=10000

Domyślny limit czasu haka w milisekundach. Użyj 0, aby całkowicie wyłączyć limit czasu.

teardownTimeout*

Typ: number
Domyślnie: 10000
CLI: --teardown-timeout=5000, --teardownTimeout=5000

Domyślny limit czasu oczekiwania na zamknięcie podczas wyłączania Vitest, w milisekundach.

silent*

Typ: boolean | 'passed-only'
Domyślnie: false
CLI: --silent, --silent=false

Wycisz wyjście konsoli z testów.

Użyj 'passed-only', aby widzieć logi tylko z nieudanych testów. Logi z nieudanych testów są drukowane po zakończeniu testu.

setupFiles

Typ: string | string[]

Ścieżka do plików konfiguracyjnych. Zostaną one uruchomione przed każdym plikiem testowym.

INFO

Edycja pliku konfiguracyjnego automatycznie wywoła ponowne uruchomienie wszystkich testów.

Możesz użyć process.env.VITEST_POOL_ID (ciąg znaków podobny do liczby całkowitej), aby rozróżnić wątki.

TIP

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

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;
}

// haki są resetowane przed każdym zestawem
afterEach(() => {
  cleanup();
});

globalThis.resetBeforeEachTest = true;

provide 2.1.0+

Typ: Partial<ProvidedContext>

Zdefiniuj wartości, do których można uzyskać dostęp w testach za pomocą metody inject.

vitest.config.jsapi.test.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    provide: {
      API_KEY: '123',
    },
  },
});

import { expect, inject, test } from 'vitest';

test('api key is defined', () => {
  expect(inject('API_KEY')).toBe('123');
});

WARNING

Właściwości muszą być ciągami znaków, a wartości muszą być serializowalne, ponieważ ten obiekt będzie przesyłany między różnymi procesami.

TIP

Jeśli używasz TypeScript, będziesz musiał rozszerzyć typ ProvidedContext dla bezpiecznego dostępu do typów:

declare module 'vitest' {
  export interface ProvidedContext {
    API_KEY: string;
  }
}

// oznacz ten plik jako moduł, aby rozszerzenie działało poprawnie
export {};

globalSetup

Typ: string | string[]

Ścieżka do globalnych plików konfiguracyjnych, względna do katalogu głównego 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 użycie wielu plików globalSetup. Funkcje setup i teardown są wykonywane sekwencyjnie, przy czym teardown w odwrotnej kolejności.

WARNING

Globalna konfiguracja uruchamia się tylko wtedy, gdy istnieje co najmniej jeden uruchomiony test. Oznacza to, że globalna konfiguracja może zacząć działać w trybie obserwacji po zmianie pliku testowego (plik testowy będzie czekał na zakończenie globalnej konfiguracji przed uruchomieniem).

Pamiętaj, że globalna konfiguracja działa w innym globalnym zakresie, więc Twoje testy nie mają dostępu do zmiennych zdefiniowanych tutaj. Możesz jednak przekazać serializowalne dane do testów za pomocą metody provide:

example.test.jsglobalSetup.ts 3.0.0+ globalSetup.ts 2.0.0+

import { inject } from 'vitest';

inject('wsPort') === 3000;

import type { TestProject } from 'vitest/node';

export default function setup(project: TestProject) {
  project.provide('wsPort', 3000);
}

declare module 'vitest' {
  export interface ProvidedContext {
    wsPort: number;
  }
}

import type { GlobalSetupContext } from 'vitest/node';

export default function setup({ provide }: GlobalSetupContext) {
  provide('wsPort', 3000);
}

declare module 'vitest' {
  export interface ProvidedContext {
    wsPort: number;
  }
}

Od Vitest 3, możesz zdefiniować niestandardową funkcję zwrotną, która zostanie wywołana, gdy Vitest ponownie uruchomi testy. Jeśli funkcja jest asynchroniczna, runner poczeka na jej zakończenie przed wykonaniem testów. Zauważ, że nie możesz dekonstruować project jak { onTestsRerun } ponieważ opiera się to na kontekście.

import type { TestProject } from 'vitest/node';

export default function setup(project: TestProject) {
  project.onTestsRerun(async () => {
    await restartDb();
  });
}

forceRerunTriggers*

Typ: string[]
Domyślnie: ['**/package.json/**', '**/vitest.config.*/**', '**/vite.config.*/**']

Wzorzec glob ścieżek plików, które wywołają ponowne uruchomienie całej paczki testów. W połączeniu z argumentem --changed uruchomi całą paczkę testów, jeśli wyzwalacz zostanie znaleziony w różnicy git.

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

test('execute a script', async () => {
  // Vitest nie może ponownie uruchomić 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 server.watch.ignored.

coverage*

Możesz użyć v8, istanbul lub niestandardowego rozwiązania do pokrycia kodu do zbierania pokrycia.

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

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

WARNING

Jeśli używasz opcji pokrycia z notacją kropkową, nie zapomnij określić --coverage.enabled. W takim przypadku nie podawaj pojedynczej opcji --coverage.

coverage.provider

Typ: 'v8' | 'istanbul' | 'custom'
Domyślnie: 'v8'
CLI: --coverage.provider=<provider>

Użyj provider, aby wybrać narzędzie do zbierania pokrycia.

coverage.enabled

Typ: boolean
Domyślnie: false
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.enabled, --coverage.enabled=false

Włącza zbieranie pokrycia. Może być nadpisane za pomocą opcji CLI --coverage.

coverage.include

Typ: string[]
Domyślnie: ['**']
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.include=<path>, --coverage.include=<path1> --coverage.include=<path2>

Lista plików uwzględnionych w pokryciu jako wzorce glob.

coverage.extension

Typ: string | string[]
Domyślnie: ['.js', '.cjs', '.mjs', '.ts', '.mts', '.tsx', '.jsx', '.vue', '.svelte', '.marko', '.astro']
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.extension=<extension>, --coverage.extension=<extension1> --coverage.extension=<extension2>

coverage.exclude

Typ: string[]
Domyślnie:

[
  'coverage/**',
  'dist/**',
  '**/node_modules/**',
  '**/[.]**',
  'packages/*/test?(s)/**',
  '**/*.d.ts',
  '**/virtual:*',
  '**/__x00__*',
  '**/\x00*',
  'cypress/**',
  'test?(s)/**',
  'test?(-*).?(c|m)[jt]s?(x)',
  '**/*{.,-}{test,spec,bench,benchmark}?(-d).?(c|m)[jt]s?(x)',
  '**/__tests__/**',
  '**/{karma,rollup,webpack,vite,vitest,jest,ava,babel,nyc,cypress,tsup,build,eslint,prettier}.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=<path>, --coverage.exclude=<path1> --coverage.exclude=<path2>

Lista plików wykluczonych z pokrycia jako wzorce glob.

Ta opcja nadpisuje wszystkie domyślne opcje. Rozszerz domyślne opcje, dodając nowe wzorce do ignorowania:

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

export default defineConfig({
  test: {
    coverage: {
      exclude: ['**/custom-pattern/**', ...coverageConfigDefaults.exclude],
    },
  },
});

UWAGA

Vitest automatycznie dodaje wzorce include plików testowych do coverage.exclude. Nie jest możliwe pokazanie pokrycia plików testowych.

coverage.all

Typ: boolean
Domyślnie: true
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.all, --coverage.all=false

Czy uwzględnić wszystkie pliki, w tym te nieprzetestowane, w raporcie.

coverage.clean

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

Wyczyść wyniki pokrycia przed uruchomieniem testów.

coverage.cleanOnRerun

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

Wyczyść raport pokrycia przy ponownym uruchomieniu w trybie obserwacji. Ustaw na false, aby zachować wyniki pokrycia z poprzedniego uruchomienia w trybie obserwacji.

coverage.reportsDirectory

Typ: string
Domyślnie: './coverage'
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.reportsDirectory=<path>

WARNING

Vitest usunie ten katalog przed uruchomieniem testów, jeśli coverage.clean jest włączone (wartość domyślna).

Katalog do zapisu raportu pokrycia.

Aby wyświetlić podgląd raportu pokrycia w wyjściu raportu HTML, ta opcja musi być ustawiona jako podkatalog katalogu raportu HTML (na przykład ./html/coverage).

coverage.reporter

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

Reportery pokrycia 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 reporterów.

Reporter ma trzy różne typy:

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

Pojedynczy lub wiele reporterów z opcjami raportu:

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

Możesz również przekazać niestandardowe reportery pokrycia. Więcej informacji znajdziesz w Przewodniku - Niestandardowy Reporter Pokrycia.

{
  reporter: [
    // Określ reporter za pomocą nazwy pakietu NPM
    '@vitest/custom-coverage-reporter',
    ['@vitest/custom-coverage-reporter', { someOption: true }],

    // Określ reporter za pomocą lokalnej ścieżki
    '/absolute/path/to/custom-reporter.cjs',
    ['/absolute/path/to/custom-reporter.cjs', { someOption: true }],
  ];
}

Możesz sprawdzić swój raport pokrycia w Vitest UI: sprawdź Vitest UI Coverage po więcej szczegółów.

coverage.reportOnFailure

Typ: boolean
Domyślnie: false
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.reportOnFailure, --coverage.reportOnFailure=false

Generuj raport pokrycia nawet wtedy, gdy testy się nie powiodą.

coverage.allowExternal

Typ: boolean
Domyślnie: false
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.allowExternal, --coverage.allowExternal=false

Zbieraj pokrycie plików spoza katalogu głównego projektu.

coverage.excludeAfterRemap 2.1.0+

Typ: boolean
Domyślnie: false
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.excludeAfterRemap, --coverage.excludeAfterRemap=false

Ponownie zastosuj wykluczenia po ponownym mapowaniu pokrycia na oryginalne źródła. Jest to przydatne, gdy pliki źródłowe są transpilowane i mogą zawierać mapy źródłowe plików nieźródłowych.

Użyj tej opcji, gdy widzisz pliki, które pojawiają się w raporcie, nawet jeśli pasują do Twoich wzorców coverage.exclude.

coverage.skipFull

Typ: boolean
Domyślnie: 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.thresholds

Opcje dla progów pokrycia.

Jeśli próg jest ustawiony na liczbę dodatnią, zostanie zinterpretowany jako minimalny wymagany procent pokrycia. Na przykład, ustawienie progu linii na 90 oznacza, że 90% linii musi być pokrytych.

Jeśli próg jest ustawiony na liczbę ujemną, zostanie potraktowany jako maksymalna dozwolona liczba niepokrytych elementów. Na przykład, ustawienie progu linii na -10 oznacza, że nie więcej niż 10 linii może być niepokrytych.

{
  coverage: {
    thresholds: {
      // Wymaga 90% pokrycia funkcji
      functions: 90,

      // Wymaga, aby nie więcej niż 10 linii było niepokrytych
      lines: -10,
    }
  }
}

coverage.thresholds.lines

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

Globalny próg dla linii.

coverage.thresholds.functions

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

Globalny próg dla funkcji.

coverage.thresholds.branches

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

Globalny próg dla gałęzi.

coverage.thresholds.statements

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

Globalny próg dla instrukcji.

coverage.thresholds.perFile

Typ: boolean
Domyślnie: false
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.thresholds.perFile, --coverage.thresholds.perFile=false

Sprawdź progi dla każdego pliku.

coverage.thresholds.autoUpdate

Typ: boolean
Domyślnie: false
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.thresholds.autoUpdate=<boolean>

Aktualizuj wszystkie wartości progów lines, functions, branches i statements w pliku konfiguracyjnym, gdy bieżące pokrycie jest lepsze niż skonfigurowane progi. Ta opcja pomaga utrzymać progi, gdy pokrycie jest poprawione.

coverage.thresholds.100

Typ: boolean
Domyślnie: false
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.thresholds.100, --coverage.thresholds.100=false

Ustawia globalne progi na 100. Skrót dla --coverage.thresholds.lines 100 --coverage.thresholds.functions 100 --coverage.thresholds.branches 100 --coverage.thresholds.statements 100.

coverage.thresholds[glob-pattern]

Typ: { statements?: number functions?: number branches?: number lines?: number }
Domyślnie: undefined
Dostępne dla dostawców: 'v8' | 'istanbul'

Ustawia progi dla plików pasujących do wzorca glob.

UWAGA

Vitest zlicza wszystkie pliki, w tym te objęte wzorcami glob, do globalnych progów pokrycia. Różni się to od zachowania Jest.

{
  coverage: {
    thresholds: {
      // Progi dla wszystkich plików
      functions: 95,
      branches: 70,

      // Progi dla pasującego wzorca glob
      'src/utils/**.ts': {
        statements: 95,
        functions: 90,
        branches: 85,
        lines: 80,
      },

      // Pliki pasujące do tego wzorca będą miały ustawione tylko progi linii.
      // Globalne progi nie są dziedziczone.
      '**/math.ts': {
        lines: 100,
      }
    }
  }
}

coverage.thresholds[glob-pattern].100 2.1.0+

Typ: boolean
Domyślnie: false
Dostępne dla dostawców: 'v8' | 'istanbul'

Ustawia progi na 100 dla plików pasujących do wzorca glob.

{
  coverage: {
    thresholds: {
      // Progi dla wszystkich plików
      functions: 95,
      branches: 70,

      // Progi dla pasującego wzorca glob
      'src/utils/**.ts': { 100: true },
      '**/math.ts': { 100: true }
    }
  }
}

coverage.ignoreEmptyLines

Typ: boolean
Domyślnie: true (false w v1)
Dostępne dla dostawców: 'v8'
CLI: --coverage.ignoreEmptyLines=<boolean>

Ignoruj puste linie, komentarze i inny kod niebędący kodem wykonawczym, np. typy Typescript. Wymaga experimentalAstAwareRemapping: false.

Ta opcja działa tylko wtedy, gdy używany kompilator usuwa komentarze i inny kod niebędący kodem wykonawczym z transpilowanego kodu. Domyślnie Vite używa ESBuild, który usuwa komentarze i typy Typescript z plików .ts, .tsx i .jsx.

Jeśli chcesz zastosować ESBuild również do innych plików, zdefiniuj je w opcjach esbuild:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  esbuild: {
    // Transpiluj wszystkie pliki za pomocą ESBuild, aby usunąć komentarze z pokrycia kodu.
    // Wymagane do działania `test.coverage.ignoreEmptyLines`:
    include: ['**/*.js', '**/*.jsx', '**/*.mjs', '**/*.ts', '**/*.tsx'],
  },
  test: {
    coverage: {
      provider: 'v8',
      ignoreEmptyLines: true,
    },
  },
});

coverage.experimentalAstAwareRemapping

Typ: boolean
Domyślnie: false
Dostępne dla dostawców: 'v8'
CLI: --coverage.experimentalAstAwareRemapping=<boolean>

Ponownie mapuj pokrycie z eksperymentalną analizą opartą na AST. Zapewnia dokładniejsze wyniki w porównaniu do trybu domyślnego.

coverage.ignoreClassMethods

Typ: string[]
Domyślnie: []
Dostępne dla dostawców: 'istanbul'
CLI: --coverage.ignoreClassMethods=<method>

Ustaw na tablicę nazw metod klas do zignorowania w pokryciu. Więcej informacji znajdziesz w dokumentacji istanbul.

coverage.watermarks

Typ:

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

Domyślnie:

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

Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.watermarks.statements=50,80, --coverage.watermarks.branches=50,80

Znaki wodne dla instrukcji, linii, gałęzi i funkcji. Więcej informacji znajdziesz w dokumentacji istanbul.

coverage.processingConcurrency

Typ: boolean
Domyślnie: Math.min(20, os.availableParallelism?.() ?? os.cpus().length)
Dostępne dla dostawców: 'v8' | 'istanbul'
CLI: --coverage.processingConcurrency=<number>

Limit współbieżności używany podczas przetwarzania wyników pokrycia.

coverage.customProviderModule

Typ: string
Dostępne dla dostawców: 'custom'
CLI: --coverage.customProviderModule=<path or module name>

Określa nazwę modułu lub ścieżkę do niestandardowego modułu dostawcy pokrycia. Więcej informacji znajdziesz w Przewodniku - Niestandardowy dostawca pokrycia.

testNamePattern*

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

Uruchom testy z pełnymi nazwami pasującymi do wzorca. Jeśli dodasz OnlyRunThis do tej właściwości, testy nie zawierające słowa OnlyRunThis w nazwie testu zostaną pominięte.

import { expect, test } from 'vitest';

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

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

open*

Typ: boolean
Domyślnie: !process.env.CI
CLI: --open, --open=false

Otwórz Vitest UI (WIP)

api

Typ: boolean | number
Domyślnie: false
CLI: --api, --api.port, --api.host, --api.strictPort

Nasłuchuj na porcie i udostępniaj API. Gdy ustawione na true, domyślny port to 51204.

browser eksperymentalne

Domyślnie: { enabled: false }
CLI: --browser=<name>, --browser.name=chrome --browser.headless

Konfiguracja do uruchamiania testów przeglądarkowych. Proszę, zapoznaj się z artykułem "Browser Config Reference".

WARNING

Jest to funkcja eksperymentalna. Zmiany łamiące kompatybilność mogą nie być zgodne z SemVer, proszę przypiąć wersję Vitest podczas jej używania.

clearMocks

Typ: boolean
Domyślnie: false

Wywoła .mockClear() na wszystkich szpiegach przed każdym testem. Spowoduje to wyczyszczenie historii mocków bez wpływu na implementacje mocków.

mockReset

Typ: boolean
Domyślnie: false

Wywoła .mockReset() na wszystkich szpiegach przed każdym testem. Spowoduje to wyczyszczenie historii mocków i zresetowanie każdej implementacji do jej pierwotnej.

restoreMocks

Typ: boolean
Domyślnie: false

Wywoła .mockRestore() na wszystkich szpiegach przed każdym testem. Spowoduje to wyczyszczenie historii mocków, przywrócenie każdej implementacji do jej pierwotnej oraz przywrócenie oryginalnych deskryptorów szpiegowanych obiektów.

unstubEnvs

Typ: boolean
Domyślnie: false

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

unstubGlobals

Typ: boolean
Domyślnie: false

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

testTransformMode

Typ: { web?, ssr? }

Określ metodę transformacji dla wszystkich modułów importowanych w teście, które pasują do wzorca glob. Domyślnie, opiera się na środowisku. Na przykład, testy ze środowiskiem JSDOM przetworzą wszystkie pliki z flagą ssr: false, a testy ze środowiskiem Node przetworzą wszystkie moduły z ssr: true.

testTransformMode.ssr

Typ: string[]
Domyślnie: []

Użyj potoku transformacji SSR dla wszystkich modułów w określonych testach.
Wtyczki Vite otrzymają flagę ssr: true podczas przetwarzania tych plików.

testTransformMode.web

Typ: string[]
Domyślnie: []

Najpierw wykonaj normalny potok transformacji (celując w przeglądarkę), a następnie wykonaj przepisanie SSR, aby uruchomić kod w Node.
Wtyczki Vite otrzymają flagę ssr: false podczas przetwarzania tych plików.

snapshotFormat*

Typ: PrettyFormatOptions

Opcje formatowania dla testowania migawek. Te opcje są przekazywane do pretty-format.

TIP

Pamiętaj, że pole plugins w tym obiekcie zostanie zignorowane.

Jeśli potrzebujesz rozszerzyć serializator migawek za pomocą wtyczek pretty-format, użyj API expect.addSnapshotSerializer lub opcji snapshotSerializers.

snapshotSerializers*

Typ: string[]
Domyślnie: []

Lista ścieżek do modułów serializatorów migawek do testowania migawek, przydatna, jeśli chcesz dodać niestandardowe serializatory migawek. Więcej informacji znajdziesz w Niestandardowy serializator.

resolveSnapshotPath*

Typ: (testPath: string, snapExtension: string, context: { config: SerializedConfig }) => string
Domyślnie: przechowuje pliki migawek w katalogu __snapshots__

Nadpisuje domyślną ścieżkę migawki. 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: !process.env.CI
CLI: --allowOnly, --allowOnly=false

Zezwalaj na testy i zestawy, które są oznaczone jako "tylko".

dangerouslyIgnoreUnhandledErrors*

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

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

passWithNoTests*

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

Vitest nie zgłosi błędu, jeśli nie zostaną znalezione żadne testy.

logHeapUsage

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

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

css

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

Skonfiguruj, czy CSS powinien być przetwarzany. Gdy wykluczony, pliki CSS zostaną zastąpione pustymi ciągami znaków, aby ominąć późniejsze przetwarzanie. Moduły CSS zwrócą proxy, aby nie wpływać na środowisko wykonawcze.

css.include

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

Wzorzec RegExp dla plików, które powinny 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 RegExp 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ć ograniczone zakresem. 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 poszanowaniem metody css.modules.generateScopedName, jeśli takową posiadasz i przetwarzanie CSS jest włączone. Domyślnie nazwa pliku będzie generowana jako _${name}_${hash}, gdzie hash zawiera nazwę pliku i jego zawartość.
non-scoped: nazwy klas nie będą haszowane.

WARNING

Domyślnie Vitest eksportuje 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
CLI: --max-concurrency=10, --maxConcurrency=10

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

Testy powyżej tego limitu zostaną umieszczone w kolejce do uruchomienia, gdy pojawi się dostępne miejsce.

cache*

Typ: false
CLI: --no-cache, --cache=false

Użyj tej opcji, jeśli chcesz wyłączyć funkcję pamięci podręcznej. W tej chwili Vitest przechowuje pamięć podręczną wyników testów, aby najpierw uruchomić dłuższe i nieudane testy.

Katalog pamięci podręcznej jest kontrolowany przez opcję Vite cacheDir:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  cacheDir: 'custom-folder/.vitest',
});

Możesz ograniczyć katalog tylko dla Vitest, używając process.env.VITEST:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  cacheDir: process.env.VITEST ? 'custom-folder/.vitest' : undefined,
});

sequence

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

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 do shardingowania i sortowania. Możesz rozszerzyć BaseSequencer z vitest/node, jeśli potrzebujesz tylko zredefiniować jedną z metod sort i shard, ale obie powinny istnieć.

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

Jeśli określono sequencer.groupOrder, sekwencer zostanie wywołany raz dla każdej grupy i puli.

groupOrder 3.2.0+

Typ: number
Domyślnie: 0

Kontroluje kolejność, w jakiej ten projekt uruchamia swoje testy, gdy używa wielu projektów.

Projekty z tym samym numerem kolejności grupy będą uruchamiane razem, a grupy są uruchamiane od najniższej do najwyższej.
Jeśli nie ustawisz tej opcji, wszystkie projekty będą uruchamiane równolegle.
Jeśli kilka projektów używa tej samej kolejności grupy, będą one uruchamiane w tym samym czasie.

To ustawienie wpływa tylko na kolejność uruchamiania projektów, a nie na kolejność testów w projekcie. Aby kontrolować izolację testów lub kolejność testów w projekcie, użyj opcji isolate i sequence.sequencer.

Przykład

Rozważ ten przykład:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    projects: [
      {
        test: {
          name: 'slow',
          sequence: {
            groupOrder: 0,
          },
        },
      },
      {
        test: {
          name: 'fast',
          sequence: {
            groupOrder: 0,
          },
        },
      },
      {
        test: {
          name: 'flaky',
          sequence: {
            groupOrder: 1,
          },
        },
      },
    ],
  },
});

Testy w tych projektach będą uruchamiane w następującej kolejności:

 0. slow  |
          |> uruchamiane razem
 0. fast  |

 1. flaky |> uruchamia się po slow i fast samodzielnie

sequence.shuffle

Typ: boolean | { files?, tests? }
Domyślnie: false
CLI: --sequence.shuffle, --sequence.shuffle=false

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

Vitest zazwyczaj używa pamięci podręcznej do sortowania testów, więc długo trwające testy zaczynają się wcześniej - to sprawia, że testy działają szybciej. Jeśli Twoje pliki i testy będą uruchamiane w losowej kolejności, stracisz tę poprawę wydajności, ale może to być przydatne do śledzenia testów, które przypadkowo zależą od innego, wcześniej uruchomionego.

sequence.shuffle.files

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

Czy losować pliki, pamiętaj, że długo trwające testy nie rozpoczną się wcześniej, jeśli włączysz tę opcję.

sequence.shuffle.tests

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

Czy losować testy.

sequence.concurrent

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

Jeśli chcesz, aby testy były uruchamiane równolegle, możesz to włączyć 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: 'stack'
CLI: --sequence.hooks=<value>

Zmienia kolejność wykonywania haków.

stack uporządkuje haki "after" w odwrotnej kolejności, haki "before" będą uruchamiane w kolejności, w jakiej zostały zdefiniowane
list uporządkuje wszystkie haki w kolejności, w jakiej zostały zdefiniowane
parallel uruchomi haki w pojedynczej grupie równolegle (haki w nadrzędnych zestawach nadal będą uruchamiane przed hakami bieżącego zestawu)

TIP

Ta opcja nie wpływa na onTestFinished. Jest ona zawsze wywoływana w odwrotnej kolejności.

sequence.setupFiles

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

Zmienia kolejność wykonywania plików konfiguracyjnych.

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

typecheck

Opcje konfiguracji środowiska testowego sprawdzania typów.

typecheck.enabled

Typ: boolean
Domyślnie: false
CLI: --typecheck, --typecheck.enabled

Włącz sprawdzanie typów obok regularnych testów.

typecheck.only

Typ: boolean
Domyślnie: false
CLI: --typecheck.only

Uruchom tylko testy sprawdzania typów, gdy sprawdzanie typów jest włączone. Podczas używania CLI, ta opcja automatycznie włączy sprawdzanie typów.

typecheck.checker

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

Jakich narzędzi używać do sprawdzania typów. Vitest uruchomi 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ć sprawdzania typów:

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 ten sam wynik co 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 nie zostanie nadpisane.

typecheck.ignoreSourceErrors

Typ: boolean
Domyślnie: false

Nie zgłaszaj błędu, jeśli Vitest znajdzie błędy poza plikami testowymi. To w ogóle nie pokaże Ci błędów niezwiązanych z testami.

Domyślnie, jeśli Vitest znajdzie błąd źródłowy, zestaw testów zakończy się 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.

typecheck.spawnTimeout

Typ: number
Domyślnie: 10_000

Minimalny czas w milisekundach potrzebny do uruchomienia sprawdzania typów.

slowTestThreshold*

Typ: number
Domyślnie: 300
CLI: --slow-test-threshold=<number>, --slowTestThreshold=<number>

Liczba milisekund, po której test lub zestaw jest uważany za wolny i zgłaszany jako taki w wynikach.

chaiConfig

Typ: { includeStack?, showDiff?, truncateThreshold? }
Domyślnie: { includeStack: false, showDiff: true, truncateThreshold: 40 }

Odpowiednik konfiguracji Chai.

chaiConfig.includeStack

Typ: boolean
Domyślnie: false

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

chaiConfig.showDiff

Typ: boolean
Domyślnie: true

Wpływa na to, czy flaga showDiff powinna być uwzględniona w zgłaszanych błędach 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 wartości rzeczywistych i oczekiwanych 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ć obcinanie.

Ta opcja konfiguracyjna wpływa na obcinanie wartości w tytułach test.each i w komunikacie o błędzie asercji.

bail

Typ: number
Domyślnie: 0
CLI: --bail=<value>

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

Domyślnie Vitest uruchomi wszystkie Twoje przypadki testowe, nawet jeśli niektóre z nich zakończą się niepowodzeniem. Może to być niepożądane w przypadku kompilacji CI, gdzie interesują Cię tylko 100% udane kompilacje i chciałbyś jak najwcześniej zatrzymać wykonywanie testów, gdy wystąpią błędy testowe. Opcja bail może być użyta do przyspieszenia uruchomień CI, zapobiegając uruchamianiu większej liczby testów, gdy wystąpiły błędy.

retry

Typ: number
Domyślnie: 0
CLI: --retry=<value>

Ponów test określoną liczbę razy, jeśli się nie powiedzie.

onConsoleLog*

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

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

Może być przydatne 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 {
      return !(log === 'message from third party library' && type === 'stdout');
    },
  },
});

onStackTrace*

Typ: (error: Error, frame: ParsedStack) => boolean | void

Zastosuj funkcję filtrowania do każdej ramki każdego śladu stosu podczas obsługi błędów. Pierwszy argument, error, jest obiektem o tych samych właściwościach co standardowy Error, ale nie jest rzeczywistą instancją.

Może być przydatne do filtrowania ramek śladu stosu z bibliotek zewnętrznych.

import type { ParsedStack } from 'vitest';
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    onStackTrace(error: Error, { file }: ParsedStack): boolean | void {
      // Jeśli napotkaliśmy ReferenceError, pokaż cały stos.
      if (error.name === 'ReferenceError') {
        return;
      }

      // Odrzuć wszystkie ramki z bibliotek zewnętrznych.
      if (file.includes('node_modules')) {
        return false;
      }
    },
  },
});

diff

Typ: string
CLI: --diff=<path>

Obiekt DiffOptions lub ścieżka do modułu, który eksportuje DiffOptions. Przydatne, jeśli chcesz dostosować wyświetlanie różnic.

Na przykład, jako obiekt konfiguracyjny:

import { defineConfig } from 'vitest/config';
import c from 'picocolors';

export default defineConfig({
  test: {
    diff: {
      aIndicator: c.bold('--'),
      bIndicator: c.bold('++'),
      omitAnnotationLines: true,
    },
  },
});

Lub jako moduł:

vitest.config.jsvitest.diff.ts

import { defineConfig } from 'vitest/config';

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

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

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

diff.expand

Typ: boolean
Domyślnie: true
CLI: --diff.expand=false

Rozwiń wszystkie wspólne linie.

diff.truncateThreshold

Typ: number
Domyślnie: 0
CLI: --diff.truncateThreshold=<path>

Maksymalna długość wyniku różnicy do wyświetlenia. Różnice powyżej tego progu zostaną obcięte. Obcinanie nie zadziała z domyślną wartością 0.

diff.truncateAnnotation

Typ: string
Domyślnie: '... Wynik różnicy został obcięty'
CLI: --diff.truncateAnnotation=<annotation>

Adnotacja, która jest wyświetlana na końcu wyniku różnicy, jeśli została obcięta.

diff.truncateAnnotationColor

Typ: DiffOptionsColor = (arg: string) => string
Domyślnie: noColor = (string: string): string => string

Kolor adnotacji obcięcia, domyślnie bez koloru.

diff.printBasicPrototype

Typ: boolean
Domyślnie: false

Drukuj podstawowy prototyp Object i Array w wyjściu różnic.

diff.maxDepth

Typ: number
Domyślnie: 20 (lub 8 przy porównywaniu różnych typów)

Ogranicz głębokość rekurencji podczas drukowania zagnieżdżonych obiektów.

fakeTimers

Typ: FakeTimerInstallOpts

Opcje, które Vitest przekaże do @sinon/fake-timers podczas używania vi.useFakeTimers().

fakeTimers.now

Typ: number | Date
Domyślnie: Date.now()

Instaluje fałszywe timery z określoną epoką Unix.

fakeTimers.toFake

Typ: ('setTimeout' | 'clearTimeout' | 'setImmediate' | 'clearImmediate' | 'setInterval' | 'clearInterval' | 'Date' | 'nextTick' | 'hrtime' | 'requestAnimationFrame' | 'cancelAnimationFrame' | 'requestIdleCallback' | 'cancelIdleCallback' | 'performance' | 'queueMicrotask')[]
Domyślnie: wszystko dostępne globalnie z wyjątkiem nextTick i queueMicrotask

Tablica z nazwami globalnych metod i API do fałszowania.

Aby mockować tylko setTimeout() i nextTick(), określ tę właściwość jako ['setTimeout', 'nextTick'].

Mockowanie nextTick nie jest obsługiwane podczas uruchamiania Vitest w node:child_process za pomocą --pool=forks. NodeJS używa process.nextTick wewnętrznie w node:child_process i zawiesza się, gdy jest mockowane. Mockowanie nextTick jest obsługiwane podczas uruchamiania Vitest z --pool=threads.

fakeTimers.loopLimit

Typ: number
Domyślnie: 10_000

Maksymalna liczba timerów, które zostaną uruchomione podczas wywoływania vi.runAllTimers().

fakeTimers.shouldAdvanceTime

Typ: boolean
Domyślnie: false

Nakazuje @sinonjs/fake-timers automatyczne zwiększanie czasu mockowanego na podstawie rzeczywistego przesunięcia czasu systemowego (np. czas mockowany zostanie zwiększony o 20 ms za każde 20 ms zmiany w rzeczywistym czasie systemowym).

fakeTimers.advanceTimeDelta

Typ: number
Domyślnie: 20

Istotne tylko w przypadku użycia z shouldAdvanceTime: true. Zwiększaj czas mockowany o advanceTimeDelta ms za każde advanceTimeDelta ms zmiany w rzeczywistym czasie systemowym.

fakeTimers.shouldClearNativeTimers

Typ: boolean
Domyślnie: true

Nakazuje fałszywym timerom czyszczenie "natywnych" (tj. nie fałszywych) timerów poprzez delegowanie do ich odpowiednich handlerów. Gdy wyłączone, może to prowadzić do potencjalnie nieoczekiwanego zachowania, jeśli timery istniały przed rozpoczęciem sesji fałszywych timerów.

workspace*

PRZESTARZAŁE

Ta opcja jest przestarzała i zostanie usunięta w następnej głównej wersji. Proszę, użyj zamiast niej projects.

Typ: string | TestProjectConfiguration[]
CLI: --workspace=./file.js
Domyślnie: vitest.{workspace,projects}.{js,ts,json} blisko pliku konfiguracyjnego lub katalogu głównego

Ścieżka do pliku konfiguracyjnego obszaru roboczego względna do katalogu głównego.

Od Vitest 3, możesz również zdefiniować tablicę obszarów roboczych w głównej konfiguracji. Jeśli workspace jest zdefiniowany w konfiguracji ręcznie, Vitest zignoruje plik vitest.workspace w katalogu głównym.

projects*

Typ: TestProjectConfiguration[]
Domyślnie: []

Tablica projektów.

isolate

Typ: boolean
Domyślnie: true
CLI: --no-isolate, --isolate=false

Uruchamiaj testy w izolowanym środowisku. Ta opcja nie ma wpływu na pule vmThreads i vmForks.

Wyłączenie tej opcji może poprawić wydajność, jeśli Twój kod nie polega na efektach ubocznych (co zazwyczaj jest prawdą w przypadku projektów ze środowiskiem node).

TIP

Możesz wyłączyć izolację dla konkretnych pul, używając właściwości poolOptions.

includeTaskLocation

Typ: boolean
Domyślnie: false

Czy właściwość location powinna być uwzględniana, gdy Vitest API otrzymuje zadania w reporterach. Jeśli masz dużo testów, to może spowodować niewielkie pogorszenie wydajności.

Właściwość location ma wartości column i line, które odpowiadają pozycji test lub describe w oryginalnym pliku.

Ta opcja zostanie automatycznie włączona, jeśli jej jawnie nie wyłączysz, a uruchamiasz Vitest z:

Vitest UI
lub używając trybu przeglądarki bez trybu headless
lub używając raportu HTML

TIP

Ta opcja nie ma wpływu, jeśli nie używasz niestandardowego kodu, który na niej polega.

snapshotEnvironment

Typ: string

Ścieżka do niestandardowej implementacji środowiska migawek. Jest to przydatne, jeśli uruchamiasz testy w środowisku, które nie obsługuje API Node.js. Ta opcja nie ma wpływu na runner przeglądarkowy.

Ten obiekt powinien mieć kształt SnapshotEnvironment i jest używany do rozwiązywania oraz odczytu/zapisu plików migawek:

export interface SnapshotEnvironment {
  getVersion: () => string;
  getHeader: () => string;
  resolvePath: (filepath: string) => Promise<string>;
  resolveRawPath: (testPath: string, rawPath: string) => Promise<string>;
  saveSnapshotFile: (filepath: string, snapshot: string) => Promise<void>;
  readSnapshotFile: (filepath: string) => Promise<string | null>;
  removeSnapshotFile: (filepath: string) => Promise<void>;
}

Możesz rozszerzyć domyślne VitestSnapshotEnvironment z punktu wejścia vitest/snapshot, jeśli potrzebujesz nadpisać tylko część API.

WARNING

Jest to opcja niskopoziomowa i powinna być używana tylko w zaawansowanych przypadkach, gdy nie masz dostępu do domyślnych API Node.js.

Jeśli potrzebujesz tylko skonfigurować funkcję migawek, użyj opcji snapshotFormat lub resolveSnapshotPath.

env

Typ: Partial<NodeJS.ProcessEnv>

Zmienne środowiskowe dostępne w process.env i import.meta.env podczas testów. Te zmienne nie będą dostępne w głównym procesie (na przykład w globalSetup).

expect

Typ: ExpectOptions

expect.requireAssertions

Typ: boolean
Domyślnie: false

To samo, co wywołanie expect.hasAssertions() na początku każdego testu. Zapewnia to, że żaden test nie przejdzie przypadkowo.

TIP

Działa to tylko z expect Vitest. Jeśli używasz asercji assert lub .should, nie będą one liczone, a Twój test zakończy się niepowodzeniem z powodu braku asercji expect.

Możesz zmienić wartość tej opcji, wywołując vi.setConfig({ expect: { requireAssertions: false } }). Konfiguracja zostanie zastosowana do każdego kolejnego wywołania expect, dopóki vi.resetConfig nie zostanie wywołane ręcznie.

expect.poll

Globalne opcje konfiguracyjne dla expect.poll. Są to te same opcje, które można przekazać do expect.poll(condition, options).

expect.poll.interval

Typ: number
Domyślnie: 50

Interwał odpytywania w milisekundach.

expect.poll.timeout

Typ: number
Domyślnie: 1000

Limit czasu odpytywania w milisekundach.

printConsoleTrace

Typ: boolean
Domyślnie: false

Zawsze drukuj ślady konsoli podczas wywoływania dowolnej metody console. Jest to przydatne do debugowania.

attachmentsDir 3.2.0+

Typ: string
Domyślnie: '.vitest-attachments'

Ścieżka katalogu do przechowywania załączników utworzonych przez context.annotate względem katalogu głównego projektu.

Konfiguracja Vitest ​

include ​

exclude ​

includeSource ​

name ​

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.interopDefault ​

deps.moduleDirectories ​

runner ​

benchmark ​

benchmark.include ​

benchmark.exclude ​

benchmark.includeSource ​

benchmark.reporters ​

benchmark.outputFile ​

benchmark.outputJson ​

benchmark.compare ​

alias ​

globals ​

environment ​

environmentOptions ​

environmentMatchGlobs ​

poolMatchGlobs ​

update* ​

watch* ​

watchTriggerPatterns 3.2.0+ * ​

root ​

dir ​

reporters* ​

outputFile* ​

pool* ​

threads* ​

forks* ​

vmThreads* ​

vmForks* ​

poolOptions* ​

poolOptions.threads ​

poolOptions.threads.maxThreads* ​

poolOptions.threads.minThreads* ​

poolOptions.threads.singleThread ​

poolOptions.threads.useAtomics* ​

poolOptions.threads.isolate ​

poolOptions.threads.execArgv* ​

poolOptions.forks ​

poolOptions.forks.maxForks* ​

poolOptions.forks.minForks* ​

poolOptions.forks.isolate ​

poolOptions.forks.singleFork ​

poolOptions.forks.execArgv* ​

poolOptions.vmThreads ​

poolOptions.vmThreads.maxThreads* ​

poolOptions.vmThreads.minThreads* ​

poolOptions.vmThreads.memoryLimit* ​

poolOptions.vmThreads.useAtomics* ​

poolOptions.vmThreads.execArgv* ​

poolOptions.vmForks* ​

poolOptions.vmForks.maxForks* ​

poolOptions.vmForks.minForks* ​

poolOptions.vmForks.memoryLimit* ​

poolOptions.vmForks.execArgv* ​

fileParallelism* ​

maxWorkers* ​

minWorkers* ​

testTimeout ​

Konfiguracja Vitest

include

exclude

includeSource

name

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.interopDefault

deps.moduleDirectories

runner

benchmark

benchmark.include

benchmark.exclude

benchmark.includeSource

benchmark.reporters

benchmark.outputFile

benchmark.outputJson

benchmark.compare

alias

globals

environment

environmentOptions

environmentMatchGlobs

poolMatchGlobs

update*

watch*

watchTriggerPatterns 3.2.0+ *

root

dir

reporters*

outputFile*

pool*

threads*

forks*

vmThreads*

vmForks*

poolOptions*

poolOptions.threads

poolOptions.threads.maxThreads*

poolOptions.threads.minThreads*

poolOptions.threads.singleThread

poolOptions.threads.useAtomics*

poolOptions.threads.isolate

poolOptions.threads.execArgv*

poolOptions.forks

poolOptions.forks.maxForks*

poolOptions.forks.minForks*

poolOptions.forks.isolate

poolOptions.forks.singleFork

poolOptions.forks.execArgv*

poolOptions.vmThreads

poolOptions.vmThreads.maxThreads*

poolOptions.vmThreads.minThreads*

poolOptions.vmThreads.memoryLimit*

poolOptions.vmThreads.useAtomics*

poolOptions.vmThreads.execArgv*

poolOptions.vmForks*

poolOptions.vmForks.maxForks*

poolOptions.vmForks.minForks*

poolOptions.vmForks.memoryLimit*

poolOptions.vmForks.execArgv*

fileParallelism*

maxWorkers*

minWorkers*

testTimeout