Configurando o Vitest

Para criar um arquivo de configuração do Vitest, siga o guia. Certifique-se de entender como a configuração do Vitest é resolvida antes de prosseguir.

WARNING

Todas as opções listadas aqui estão localizadas em uma propriedade test dentro da configuração:

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

TIP

Além das opções a seguir, você também pode usar qualquer opção de configuração do Vite. Por exemplo, define para definir variáveis globais ou resolve.alias para definir aliases.

Todas as opções de configuração que não são suportadas dentro de uma configuração de projeto workspace têm a indicação * ao lado delas.

include

Tipo: string[]
Padrão: ['**/*.{test,spec}.?(c|m)[jt]s?(x)']
CLI: vitest [...include], vitest **/*.test.js

Uma lista de padrões globais que correspondem aos seus arquivos de teste.

exclude

Tipo: string[]
Padrão: ['**/node_modules/**', '**/dist/**', '**/cypress/**', '**/.{idea,git,cache,output,temp}/**', '**/{karma,rollup,webpack,vite,vitest,jest,ava,babel,nyc,cypress,tsup,build}.config.*']
CLI: vitest --exclude "**/excluded-file"

Uma lista de padrões globais que devem ser excluídos da busca por arquivos de teste.

WARNING

Esta opção não influencia a cobertura de código. Se você precisar remover certos arquivos do relatório de cobertura, use coverage.exclude.

Esta é a única opção que não sobrescreve sua configuração se você a fornecer com uma flag da CLI. Todos os padrões globais adicionados via flag --exclude serão adicionados ao exclude da configuração.

includeSource

Tipo: string[]
Padrão: []

Inclui globs para arquivos de teste in-source.

Quando definido, o Vitest executará todos os arquivos correspondentes que contenham import.meta.vitest.

server 0.34.0+

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

Opções do servidor Vite-Node.

server.sourcemap

Tipo: 'inline' | boolean
Padrão: 'inline'

Injeta source maps inline nos módulos.

server.debug

Tipo: { dumpModules?, loadDumppedModules? }

Opções do depurador Vite-Node.

server.debug.dumpModules

Tipo: boolean | string

Exporta o módulo transformado para o sistema de arquivos. Passar uma string irá exportar para o caminho especificado.

server.debug.loadDumppedModules

Tipo: boolean

Lê o módulo exportado do sistema de arquivos sempre que existir. Útil para depurar, modificando o resultado do despejo do sistema de arquivos.

server.deps

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

Configurações para resolução de dependências.

server.deps.external

Tipo: (string | RegExp)[]
Padrão: [/\/node_modules\//]

Externalizar significa que o Vite irá desviar o pacote para o Node nativo. As dependências externalizadas não terão os transformadores e resolvedores do Vite aplicados, portanto, não suportam HMR no recarregamento. Por padrão, todos os pacotes dentro de node_modules são externalizados.

Essas opções suportam nomes de pacotes como estão escritos em node_modules ou especificados dentro de deps.moduleDirectories. Por exemplo, o pacote @company/some-name localizado dentro de packages/some-name deve ser especificado como some-name, e packages deve ser incluído em deps.moduleDirectories. Basicamente, o Vitest sempre verifica o caminho do arquivo, não o nome real do pacote.

Se regexp for usado, o Vitest o aplica no caminho do arquivo, não no nome do pacote.

server.deps.inline

Tipo: (string | RegExp)[] | true
Padrão: []

O Vite processará módulos embutidos. Isso pode ser útil para lidar com pacotes que enviam arquivos .js no formato ESM (que o Node não consegue lidar).

Se true, todas as dependências serão inlined. Todas as dependências, especificadas em ssr.noExternal serão inlined por padrão.

server.deps.fallbackCJS

Tipo boolean
Padrão: false

Quando uma dependência é um pacote ESM válido, tenta inferir a versão CJS com base no caminho. Isso pode ser útil se uma dependência tiver o arquivo ESM incorreto.

Isso pode potencialmente causar algum desalinhamento se um pacote tiver uma lógica diferente nos modos ESM e CJS.

server.deps.cacheDir

Tipo string
Padrão: 'node_modules/.vite'

Diretório para salvar arquivos de cache.

deps

Tipo: { optimizer?, ... }

Configurações para resolução de dependências.

deps.optimizer 0.34.0+

Tipo: { ssr?, web? }
Veja também: Opções de Otimização de Dependências

Ativa a otimização de dependências. Se você tiver muitos testes, isso pode melhorar o desempenho deles. Antes do Vitest 0.34.0, era chamado de deps.experimentalOptimizer.

Quando o Vitest encontra uma biblioteca externa listada em include, ela será agrupada em um único arquivo usando esbuild e importada como um módulo único. Isso é bom por vários motivos:

Importar pacotes com muitas importações é custoso. Ao agrupá-los em um arquivo, podemos economizar muito tempo.
Importar bibliotecas de UI é caro porque elas não foram feitas para serem executadas dentro do Node.js.
Sua configuração de alias agora é respeitada dentro dos pacotes agrupados.
O código nos seus testes está sendo executado de forma mais similar a como é executado no navegador.

Esteja ciente de que apenas os pacotes na opção deps.optimizer?.[mode].include são agrupados (alguns plugins preenchem isso automaticamente, como o Svelte). Você pode ler mais sobre as opções disponíveis na documentação do Vite (o Vitest não suporta as opções disable e noDiscovery). Por padrão, o Vitest usa optimizer.web para ambientes jsdom e happy-dom e optimizer.ssr para ambientes node e edge, mas é configurável por transformMode.

Essas opções também herdam sua configuração optimizeDeps (para web, o Vitest estenderá optimizeDeps, para ssr - ssr.optimizeDeps). Se você redefinir a opção include/exclude em deps.optimizer, ela estenderá seu optimizeDeps ao executar testes. O Vitest remove automaticamente as mesmas opções de include, se elas estiverem listadas em exclude.

TIP

Você não poderá editar o código em node_modules para depuração, pois o código real está localizado no diretório cacheDir ou em test.cache.dir. Se você quiser depurar com instruções console.log, edite-o diretamente ou force o rebundling com a opção deps.optimizer?.[mode].force.

deps.optimizer.{mode}.enabled

Tipo: boolean
Padrão: false desde o Vitest 1.3.0

Ativa a otimização de dependências.

WARNING

Esta opção só funciona com o Vite 4.3.2 e superior.

deps.web 0.34.2+

Tipo: { transformAssets?, ... }

Opções que são aplicadas a arquivos externos quando o modo de transformação é definido como web. Por padrão, jsdom e happy-dom usam o modo web, enquanto os ambientes node e edge usam o modo de transformação ssr, portanto, essas opções não terão efeito em arquivos dentro desses ambientes.

Normalmente, os arquivos dentro de node_modules são externalizados, mas essas opções também afetam os arquivos em server.deps.external.

deps.web.transformAssets

Tipo: boolean
Padrão: true

Define se o Vitest deve processar arquivos de recursos (arquivos .png, .svg, .jpg, etc.) e resolvê-los da mesma forma que o Vite faz no navegador.

Este módulo terá uma exportação padrão igual ao caminho do asset, se nenhuma consulta for especificada.

WARNING

No momento, esta opção só funciona com pools vmThreads e vmForks.

deps.web.transformCss

Tipo: boolean
Padrão: true

O Vitest deve processar arquivos CSS (arquivos .css, .scss, .sass, etc.) e resolvê-los da mesma forma que o Vite faz no navegador.

Se os arquivos CSS estiverem desativados com as opções css, esta opção apenas suprimirá os erros ERR_UNKNOWN_FILE_EXTENSION.

WARNING

No momento, esta opção só funciona com pools vmThreads e vmForks.

deps.web.transformGlobPattern

Tipo: RegExp | RegExp[]
Padrão: []

Padrão Regexp para corresponder a arquivos externos que devem ser transformados.

Por padrão, os arquivos dentro de node_modules são externalizados e não transformados, a menos que seja CSS ou um ativo, e a opção correspondente não esteja desativada.

WARNING

No momento, esta opção só funciona com pools vmThreads e vmForks.

deps.interopDefault

Tipo: boolean
Padrão: true

Interpreta o default de um módulo CJS como exportações nomeadas. Algumas dependências apenas agrupam módulos CJS e não usam exportações nomeadas que o Node.js pode analisar estaticamente quando um pacote é importado usando a sintaxe import em vez de require. Ao importar essas dependências no ambiente Node usando exportações nomeadas, você verá este erro:

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.

O Vitest não faz análise estática e não pode falhar antes de seu código em execução, então você provavelmente verá este erro ao executar testes, se este recurso estiver desativado:

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

Por padrão, o Vitest presume que você está usando um bundler para evitar isso e não falhará, mas você pode desativar este comportamento manualmente, se seu código não for processado.

deps.moduleDirectories

Tipo: string[]
Padrão: ['node_modules']

Uma lista de diretórios que devem ser considerados como diretórios de módulo. Esta configuração afeta o comportamento de vi.mock: quando nenhuma fábrica é fornecida e o caminho do que você está simulando corresponde a um dos valores moduleDirectories, o Vitest tentará resolver o mock procurando uma pasta __mocks__ na raiz do projeto.

Esta opção também afetará se um arquivo deve ser tratado como um módulo ao externalizar as dependências. Por padrão, o Vitest importa módulos externos com o Node.js nativo, ignorando a etapa de transformação do Vite.

Definir esta opção irá sobrescrever o padrão, se você deseja ainda pesquisar node_modules para pacotes, inclua-o junto com quaisquer outras opções:

import { defineConfig } from 'vitest/config';

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

runner

Tipo: VitestRunnerConstructor
Padrão: node, ao executar testes, ou benchmark, ao executar benchmarks

Caminho para um executor de testes personalizado. Este é um recurso avançado e deve ser usado com executores de biblioteca personalizados. Você pode ler mais sobre isso na documentação.

benchmark

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

Opções usadas ao executar vitest bench.

benchmark.include

Tipo: string[]
Padrão: ['**/*.{bench,benchmark}.?(c|m)[jt]s?(x)']

Inclui globs para arquivos de teste de benchmark.

benchmark.exclude

Tipo: string[]
Padrão: ['node_modules', 'dist', '.idea', '.git', '.cache']

Exclui globs para arquivos de teste de benchmark.

benchmark.includeSource

Tipo: string[]
Padrão: []

Inclui globs para arquivos de teste de benchmark in-source. Esta opção é semelhante a includeSource.

Quando definido, o Vitest executará todos os arquivos correspondentes que contenham import.meta.vitest.

benchmark.reporters

Tipo: Arrayable<BenchmarkBuiltinReporters | Reporter>
Padrão: 'default'

Relatório personalizado para saída. Pode conter um ou mais nomes de relatório integrados, instâncias de reporter e/ou caminhos para reporters personalizados.

benchmark.outputFile

Tipo: string | Record<string, string>

Escreve os resultados do benchmark em um arquivo quando a opção --reporter=json também é especificada. Ao fornecer um objeto em vez de uma string, você pode definir saídas individuais ao usar vários reporters.

Para fornecer um objeto via comando CLI, use a seguinte sintaxe: --outputFile.json=./path --outputFile.junit=./other-path.

benchmark.outputJson 1.6.0+

Tipo: string | undefined
Padrão: undefined

Um caminho de arquivo para salvar o resultado do benchmark, que pode ser usado para a opção --compare posteriormente.

Por exemplo:

# save result
git checkout main
vitest bench --outputJson main.json

# compare with main
git checkout feature
vitest bench --compare main.json

benchmark.compare 1.6.0+

Tipo: string | undefined
Padrão: undefined

Um caminho de arquivo para um resultado de benchmark anterior para comparar com as execuções atuais.

alias

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

Define aliases personalizados ao executar testes. Eles serão mesclados com aliases de resolve.alias.

WARNING

O Vitest usa primitivas SSR do Vite para executar testes, o que acarreta certas armadilhas.

Os aliases afetam apenas os módulos importados diretamente com uma palavra-chave import por um módulo inlined (todo o código-fonte é inlined por padrão).
O Vitest não suporta o aliasing de chamadas require.
Se você estiver criando um alias para uma dependência externa (por exemplo, react -> preact), talvez queira criar um alias para os pacotes reais em node_modules para que funcione com dependências externalizadas. Tanto o Yarn quanto o pnpm suportam aliasing via o prefixo npm:.

globals

Tipo: boolean
Padrão: false
CLI: --globals, --globals=false

Por padrão, o vitest não fornece APIs globais para clareza. Se você preferir usar as APIs globalmente como o Jest, você pode passar a opção --globals para CLI ou adicionar globals: true na configuração.

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

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

Para que o TypeScript funcione com as APIs globais, adicione vitest/globals ao campo types no seu tsconfig.json.

json

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

Se você já estiver utilizando unplugin-auto-import no seu projeto, você também pode usá-lo diretamente para fazer a importação automática dessas APIs.

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

export default defineConfig({
  plugins: [
    AutoImport({
      imports: ['vitest'],
      dts: true, // Gera declaração TypeScript
    }),
  ],
});

environment

Tipo: 'node' | 'jsdom' | 'happy-dom' | 'edge-runtime' | string
Padrão: 'node'
CLI: --environment=<env>

Define o ambiente a ser utilizado para os testes. O ambiente padrão do Vitest é o Node.js. Para aplicações web, você pode usar um ambiente similar ao navegador com jsdom ou happy-dom. Para edge functions, utilize o ambiente edge-runtime.

Você pode especificar um ambiente diferente para um arquivo de teste adicionando um docblock @vitest-environment ou um comentário no início do arquivo:

Estilo Docblock:

/**
 * @vitest-environment jsdom
 */

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

Estilo Comentário:

// @vitest-environment happy-dom

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

Para compatibilidade com o Jest, o @jest-environment também é suportado:

/**
 * @jest-environment jsdom
 */

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

Se você executar o Vitest com a flag --isolate=false, os testes serão executados nesta ordem: node, jsdom, happy-dom, edge-runtime, custom environments (ambientes personalizados). Isso significa que testes com o mesmo ambiente serão agrupados, mas a execução continuará sequencial.

A partir da versão 0.23.0, você pode definir um ambiente personalizado. Quando um ambiente não nativo é utilizado, o Vitest tentará carregar o pacote vitest-environment-${name}. Este pacote deve exportar um objeto com o formato de Environment:

import type { Environment } from 'vitest';

export default <Environment>{
  name: 'custom',
  transformMode: 'ssr',
  setup() {
    // custom setup
    return {
      teardown() {
        // chamado após todos os testes com este ambiente terem sido executados
      },
    };
  },
};

O Vitest também expõe builtinEnvironments através da chave vitest/environments, caso você queira estendê-lo. Mais informações sobre como estender ambientes podem ser encontradas neste guia.

TIP

Desde o Vitest 1.3.0, o ambiente jsdom expõe a variável global jsdom igual à instância atual do JSDOM. Para que o TypeScript a reconheça, adicione vitest/jsdom ao seu tsconfig.json ao usar este ambiente:

json

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

environmentOptions

Tipo: Record<'jsdom' | string, unknown>
Padrão: {}

Opções passadas para o método setup do environment atual. Por padrão, você pode configurar apenas as opções do JSDOM, se estiver usando-o como ambiente de teste.

environmentMatchGlobs

Tipo: [string, EnvironmentName][]
Padrão: []

Atribui automaticamente o ambiente com base em globs (padrões de caminho de arquivo). A primeira correspondência será utilizada.

Exemplo:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    environmentMatchGlobs: [
      // todos os testes em tests/dom serão executados em jsdom
      ['tests/dom/**', 'jsdom'],
      // todos os testes em tests/ com .edge.test.ts serão executados em edge-runtime
      ['**/*.edge.test.ts', 'edge-runtime'],
      // ...
    ],
  },
});

poolMatchGlobs 0.29.4+

Tipo: [string, 'threads' | 'forks' | 'vmThreads' | 'vmForks' | 'typescript'][]
Padrão: []

Atribui automaticamente o pool (conjunto de processos) no qual os testes serão executados com base em globs. A primeira correspondência será utilizada.

Exemplo:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolMatchGlobs: [
      // todos os testes no diretório "worker-specific" serão executados dentro de um worker como se você tivesse habilitado `--pool=threads` para eles,
      ['**/tests/worker-specific/**', 'threads'],
      // execute todos os testes no diretório "browser" em um navegador real
      ['**/tests/browser/**', 'browser'],
      // todos os outros testes serão executados com base nas opções "browser.enabled" e "threads", se você não especificou outros globs
      // ...
    ],
  },
});

update*

Tipo: boolean
Padrão: false
CLI: -u, --update, --update=false

Atualiza os arquivos de snapshot. Isso atualizará todos os snapshots alterados e excluirá os que não são mais necessários.

watch*

Tipo: boolean
Padrão: !process.env.CI
CLI: -w, --watch, --watch=false

Habilita o modo de observação (watch mode).

root

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

Diretório raiz do projeto.

reporters*

Tipo: Reporter | Reporter[]
Padrão: 'default'
CLI: --reporter=<name>, --reporter=<name1> --reporter=<name2>

Repórteres customizados para a saída. Os repórteres podem ser uma instância de Reporter, uma string para selecionar repórteres embutidos ou um caminho para uma implementação customizada (ex: './path/to/reporter.ts', '@scope/reporter').

outputFile*

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

Escreve os resultados dos testes em um arquivo quando a opção --reporter=json, --reporter=html ou --reporter=junit também é especificada. Ao fornecer um objeto em vez de uma string, você pode definir saídas individuais ao usar múltiplos repórteres.

pool* 1.0.0+

Tipo: 'threads' | 'forks' | 'vmThreads' | 'vmForks'
Padrão: 'threads'
CLI: --pool=threads

O pool usado para executar os testes.

threads*

Habilita multithreading usando tinypool (um fork leve de Piscina). Ao usar threads, você não pode usar APIs relacionadas ao processo, como process.chdir(). Algumas bibliotecas escritas em linguagens nativas, como Prisma, bcrypt e canvas, podem apresentar problemas ao serem executadas em múltiplas threads e encontrar falhas de segmentação (segfaults). Nesses casos, é aconselhável usar o pool forks.

forks*

Semelhante ao pool threads, mas usa child_process em vez de worker_threads através de tinypool. A comunicação entre os testes e o processo principal não é tão rápida quanto com o pool threads. APIs relacionadas ao processo, como process.chdir(), estão disponíveis no pool forks.

vmThreads*

Executa os testes usando contexto VM (dentro de um ambiente sandboxed) em um pool threads.

Isso pode fazer com que os testes sejam executados mais rapidamente, mas o módulo VM é instável ao executar código ESM. Seus testes podem vazar memória. Para mitigar isso, considere editar manualmente o valor de poolOptions.vmThreads.memoryLimit.

WARNING

Executar código em um sandbox tem algumas vantagens (testes mais rápidos), mas também apresenta desvantagens.

Os globais dentro de módulos nativos, como (fs, path, etc), diferem dos globais presentes em seu ambiente de teste. Como resultado, qualquer erro lançado por esses módulos nativos referenciará um construtor de Error diferente em comparação com o usado em seu código:

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

Importar módulos ES os armazena em cache indefinidamente, o que introduz vazamentos de memória se você tiver muitos contextos (arquivos de teste). Não há API no Node.js que limpe esse cache.
Acessar globais leva mais tempo em um ambiente sandbox.

Esteja ciente desses problemas ao usar esta opção. A equipe do Vitest não pode corrigir nenhum dos problemas do nosso lado.

vmForks*

Semelhante ao pool vmThreads, mas usa child_process em vez de worker_threads através de tinypool. A comunicação entre os testes e o processo principal não é tão rápida quanto com o pool vmThreads. APIs relacionadas ao processo, como process.chdir(), estão disponíveis no pool vmForks. Esteja ciente de que este pool tem as mesmas desvantagens listadas em vmThreads.

poolOptions* 1.0.0+

Tipo: Record<'threads' | 'forks' | 'vmThreads' | 'vmForks', {}>
Padrão: {}

poolOptions.threads

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      threads: {
        // Opções relacionadas a Threads aqui
      },
    },
  },
});

poolOptions.threads.maxThreads*

Tipo: number
Padrão: CPUs disponíveis

Número máximo de threads. Você também pode usar a variável de ambiente VITEST_MAX_THREADS.

poolOptions.threads.minThreads*

Tipo: number
Padrão: CPUs disponíveis

Número mínimo de threads. Você também pode usar a variável de ambiente VITEST_MIN_THREADS.

poolOptions.threads.singleThread

Tipo: boolean
Padrão: false

Executa todos os testes com o mesmo ambiente dentro de uma única thread de worker. Isso desabilitará o isolamento de módulo incorporado (seu código fonte ou código inlined ainda será reavaliado para cada teste), mas pode acelerar o desempenho do teste.

WARNING

Mesmo que esta opção force os testes a serem executados um após o outro, ela é diferente de --runInBand do Jest. O Vitest usa workers não apenas para executar testes em paralelo, mas também para fornecer isolamento. Ao desabilitar esta opção, seus testes serão executados sequencialmente, mas no mesmo contexto global, então você deve fornecer o isolamento você mesmo.

Isso pode causar diversos problemas se você estiver confiando no estado global (frameworks de frontend normalmente dependem disso) ou se seu código depende do ambiente para ser definido separadamente para cada teste. Mas pode acelerar seus testes (até 3 vezes mais rápido) que não dependem necessariamente do estado global ou podem facilmente contornar isso.

poolOptions.threads.useAtomics*

Tipo: boolean
Padrão: false

Usa Atomics para sincronizar threads.

Isso pode melhorar o desempenho em alguns casos, mas pode causar falha de segmentação (segfault) em versões mais antigas do Node.

poolOptions.threads.isolate

Tipo: boolean
Padrão: true

Isola o ambiente para cada arquivo de teste.

poolOptions.threads.execArgv*

Tipo: string[]
Padrão: []

Passa argumentos adicionais para node nas threads. Veja Command-line API | Node.js para mais informações.

WARNING

Tenha cuidado ao usar, pois algumas opções podem causar o travamento do worker, por exemplo, --prof, --title. Veja https://github.com/nodejs/node/issues/41103.

poolOptions.forks

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      forks: {
        // Opções relacionadas a Forks aqui
      },
    },
  },
});

poolOptions.forks.maxForks*

Tipo: number
Padrão: CPUs disponíveis

Número máximo de forks.

poolOptions.forks.minForks*

Tipo: number
Padrão: CPUs disponíveis

Número mínimo de forks.

poolOptions.forks.isolate

Tipo: boolean
Padrão: true

Isola o ambiente para cada arquivo de teste.

poolOptions.forks.singleFork

Tipo: boolean
Padrão: false

Executa todos os testes com o mesmo ambiente dentro de um único processo filho. Isso desabilitará o isolamento de módulo incorporado (seu código fonte ou código inlined ainda será reavaliado para cada teste), mas pode acelerar o desempenho do teste.

WARNING

Mesmo que esta opção force os testes a serem executados um após o outro, ela é diferente de --runInBand do Jest. O Vitest usa processos filhos não apenas para executar testes em paralelo, mas também para fornecer isolamento. Ao desabilitar esta opção, seus testes serão executados sequencialmente, mas no mesmo contexto global, então você deve fornecer o isolamento você mesmo.

poolOptions.forks.execArgv*

Tipo: string[]
Padrão: []

Passa argumentos adicionais para o processo node nos processos filhos. Veja Command-line API | Node.js para mais informações.

WARNING

Tenha cuidado ao usar, pois algumas opções podem causar o travamento do worker, por exemplo, --prof, --title. Veja https://github.com/nodejs/node/issues/41103.

poolOptions.vmThreads

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      vmThreads: {
        // Opções relacionadas a VM threads aqui
      },
    },
  },
});

poolOptions.vmThreads.maxThreads*

Tipo: number
Padrão: CPUs disponíveis

Número máximo de threads. Você também pode usar a variável de ambiente VITEST_MAX_THREADS.

poolOptions.vmThreads.minThreads*

Tipo: number
Padrão: CPUs disponíveis

Número mínimo de threads. Você também pode usar a variável de ambiente VITEST_MIN_THREADS.

poolOptions.vmThreads.memoryLimit*

Tipo: string | number
Padrão: 1 / CPU Cores

Especifica o limite de memória para os workers antes de serem reutilizados. Este valor depende muito do seu ambiente, por isso é melhor especificá-lo manualmente em vez de confiar no padrão.

TIP

A implementação é baseada no workerIdleMemoryLimit do Jest.

O limite pode ser especificado de várias maneiras diferentes e, seja qual for o resultado, Math.floor é usado para transformá-lo em um valor inteiro:

<= 1 - O valor é considerado uma porcentagem da memória do sistema. Portanto, 0.5 define o limite de memória do worker para metade da memória total do sistema
\> 1 - Considerado um valor de byte fixo. Devido à regra anterior, se você quisesse um valor de 1 byte você poderia usar 1.1.
Com unidades
- 50% - Como acima, uma porcentagem da memória total do sistema
- 100KB, 65MB, etc - Com unidades para denotar um limite de memória fixo.
- K / KB - Kilobytes (x1000)
- KiB - Kibibytes (x1024)
- M / MB - Megabytes
- MiB - Mebibytes
- G / GB - Gigabytes
- GiB - Gibibytes

WARNING

O limite de memória baseado em porcentagem não funciona em workers Linux CircleCI devido à memória incorreta do sistema sendo relatada.

poolOptions.vmThreads.useAtomics*

Tipo: boolean
Padrão: false

Usa Atomics para sincronizar threads.

Isso pode melhorar o desempenho em alguns casos, mas pode causar falha de segmentação (segfault) em versões mais antigas do Node.

poolOptions.vmThreads.execArgv*

Tipo: string[]
Padrão: []

Passa argumentos adicionais para o processo node no contexto VM. Veja Command-line API | Node.js para mais informações.

WARNING

Tenha cuidado ao usar, pois algumas opções podem causar o travamento do worker, por exemplo, --prof, --title. Veja https://github.com/nodejs/node/issues/41103.

poolOptions.vmForks

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    poolOptions: {
      vmForks: {
        // Opções relacionadas a VM forks aqui
      },
    },
  },
});

poolOptions.vmForks.maxForks*

Tipo: number
Padrão: CPUs disponíveis

Número máximo de forks. Você também pode usar a variável de ambiente VITEST_MAX_FORKS.

poolOptions.vmForks.minForks*

Tipo: number
Padrão: CPUs disponíveis

Número mínimo de forks. Você também pode usar a variável de ambiente VITEST_MIN_FORKS.

poolOptions.vmForks.memoryLimit*

Tipo: string | number
Padrão: 1 / CPU Cores

Especifica o limite de memória para os workers antes de serem reutilizados. Este valor depende muito do seu ambiente, por isso é melhor especificá-lo manualmente em vez de confiar no padrão. O cálculo do valor é descrito em poolOptions.vmThreads.memoryLimit

poolOptions.vmForks.execArgv*

Tipo: string[]
Padrão: []

Passa argumentos adicionais para o processo node no contexto VM. Veja Command-line API | Node.js para mais informações.

WARNING

Tenha cuidado ao usar, pois algumas opções podem causar o travamento do worker, por exemplo, --prof, --title. Veja https://github.com/nodejs/node/issues/41103.

fileParallelism 1.1.0+

Tipo: boolean
Padrão: true
CLI: --no-file-parallelism, --fileParallelism=false

Define se todos os arquivos de teste devem ser executados em paralelo. Definir como false irá sobrescrever as opções maxWorkers e minWorkers para 1.

TIP

Essa opção não afeta os testes executados dentro do mesmo arquivo. Para executá-los em paralelo, use a opção concurrent em describe ou através de uma configuração.

maxWorkers 1.1.0+

Tipo: number

Número máximo de workers para executar os testes. poolOptions.{threads,vmThreads}.maxThreads/poolOptions.forks.maxForks têm maior prioridade.

minWorkers 1.1.0+

Tipo: number

Número mínimo de workers para executar os testes. poolOptions.{threads,vmThreads}.minThreads/poolOptions.forks.maxForks têm maior prioridade.

testTimeout

Tipo: number
Padrão: 5000
CLI: --test-timeout=5000, --testTimeout=5000

Tempo limite padrão para um teste, em milissegundos.

hookTimeout

Tipo: number
Padrão: 10000
CLI: --hook-timeout=10000, --hookTimeout=10000

Tempo limite padrão para um hook, em milissegundos.

teardownTimeout*

Tipo: number
Padrão: 10000
CLI: --teardown-timeout=5000, --teardownTimeout=5000

Tempo limite padrão para aguardar a finalização quando o Vitest é encerrado, em milissegundos.

silent*

Tipo: boolean
Padrão: false
CLI: --silent, --silent=false

Suprime a saída do console dos testes.

setupFiles

Tipo: string | string[]

Caminho para os arquivos de configuração. Eles serão executados antes de cada arquivo de teste.

INFO

Alterar os arquivos de configuração irá disparar a reexecução de todos os testes.

Você pode usar process.env.VITEST_POOL_ID (string semelhante a um inteiro) internamente para distinguir entre threads.

TIP

Se você estiver executando --isolate=false, este arquivo de configuração será executado no mesmo escopo global várias vezes. Isso significa que você está acessando o mesmo objeto global antes de cada teste, então certifique-se de não repetir a mesma ação desnecessariamente.

Por exemplo, você pode confiar em uma variável global:

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

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

// hooks are reset before each suite
afterEach(() => {
  cleanup();
});

globalThis.resetBeforeEachTest = true;

globalSetup

Tipo: string | string[]

Caminho para os arquivos de configuração global, relativo à raiz do projeto.

Um arquivo de configuração global pode exportar funções nomeadas setup e teardown ou uma função default que retorna uma função de finalização (exemplo).

INFO

Vários arquivos globalSetup são permitidos. As funções setup e teardown são executadas sequencialmente, com teardown em ordem inversa.

WARNING

Desde o Vitest 1.0.0-beta, a configuração global é executada apenas se houver pelo menos um teste em execução. Isso significa que a configuração global pode começar a ser executada durante o modo de observação após a alteração de um arquivo de teste (o arquivo de teste aguardará a conclusão da configuração global antes de ser executado).

Esteja ciente de que a configuração global está sendo executada em um escopo global diferente, portanto, seus testes não têm acesso às variáveis definidas aqui. No entanto, desde a versão 1.0.0, você pode passar dados serializáveis para os testes através do método provide:

globalSetup.jsglobalSetup.tsexample.test.js

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

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

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

// You can also extend `ProvidedContext` type
// to have type safe access to `provide/inject` methods:
declare module 'vitest' {
  export interface ProvidedContext {
    wsPort: number;
  }
}

import { inject } from 'vitest';

inject('wsPort') === 3000;

watchExclude*

Tipo: string[]
Padrão: ['**/node_modules/**', '**/dist/**']
Obsoleto: use server.watch.ignored

Padrão glob de caminhos de arquivos a serem ignorados durante o modo de observação.

forceRerunTriggers*

Tipo: string[]
Padrão: ['**/package.json/**', '**/vitest.config.*/**', '**/vite.config.*/**']

Padrão Glob de caminhos de arquivos que irão disparar a reexecução de toda a suíte de testes. Quando combinado com o argumento --changed, executará toda a suíte de testes se o gatilho for encontrado no diff do Git.

Útil se você estiver testando a chamada de comandos CLI, porque o Vite não consegue construir um gráfico de módulos:

test('execute a script', async () => {
  // Vitest cannot rerun this test, if content of `dist/index.js` changes
  await execa('node', ['dist/index.js']);
});

TIP

Certifique-se de que seus arquivos não estão excluídos por watchExclude.

coverage*

Você pode usar v8, istanbul ou uma solução de cobertura customizada para a coleta de cobertura.

Você pode fornecer opções de cobertura para a CLI com notação por pontos:

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

WARNING

Se você estiver usando opções de cobertura com notação por pontos, não se esqueça de especificar --coverage.enabled. Não forneça uma única opção --coverage nesse caso.

coverage.provider

Tipo: 'v8' | 'istanbul' | 'custom'
Padrão: 'v8'
CLI: --coverage.provider=<provider>

Use provider para selecionar a ferramenta para coleta de cobertura.

coverage.enabled

Tipo: boolean
Padrão: false
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.enabled, --coverage.enabled=false

Habilita a coleta de cobertura. Pode ser sobrescrita usando a opção CLI --coverage.

coverage.include

Tipo: string[]
Padrão: ['**']
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.include=<path>, --coverage.include=<path1> --coverage.include=<path2>

Lista de arquivos incluídos na cobertura, utilizando padrões glob.

coverage.extension

Tipo: string | string[]
Padrão: ['.js', '.cjs', '.mjs', '.ts', '.mts', '.cts', '.tsx', '.jsx', '.vue', '.svelte', '.marko']
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.extension=<extension>, --coverage.extension=<extension1> --coverage.extension=<extension2>

coverage.exclude

Tipo: string[]
Padrão:

[
  'coverage/**',
  'dist/**',
  '**/[.]**',
  'packages/*/test?(s)/**',
  '**/*.d.ts',
  '**/virtual:*',
  '**/__x00__*',
  '**/\x00*',
  'cypress/**',
  'test?(s)/**',
  'test?(-*).?(c|m)[jt]s?(x)',
  '**/*{.,-}{test,spec}?(-d).?(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}',
];

Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.exclude=<path>, --coverage.exclude=<path1> --coverage.exclude=<path2>

Lista de arquivos excluídos da cobertura, utilizando padrões glob.

Esta opção sobrescreve todas as opções padrão. Estenda as opções padrão ao adicionar novos padrões para ignorar:

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

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

coverage.all

Tipo: boolean
Padrão: true (desde o Vitest 1.0.0)
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.all, --coverage.all=false

Se deve incluir todos os arquivos, incluindo os não testados, no relatório.

coverage.clean

Tipo: boolean
Padrão: true
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.clean, --coverage.clean=false

Limpa os resultados da cobertura antes de executar os testes.

coverage.cleanOnRerun

Tipo: boolean
Padrão: true
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.cleanOnRerun, --coverage.cleanOnRerun=false

Limpa o relatório de cobertura na reexecução durante o modo de observação.

coverage.reportsDirectory

Tipo: string
Padrão: './coverage'
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.reportsDirectory=<path>

WARNING

O Vitest irá excluir este diretório antes de executar os testes se coverage.clean estiver habilitado (valor padrão).

Diretório para gravar o relatório de cobertura.

Para visualizar o relatório de cobertura na saída do HTML reporter, esta opção deve ser definida como um subdiretório do diretório do relatório html (por exemplo, ./html/coverage).

coverage.reporter

Tipo: string | string[] | [string, {}][]
Padrão: ['text', 'html', 'clover', 'json']
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.reporter=<reporter>, --coverage.reporter=<reporter1> --coverage.reporter=<reporter2>

Relatores de cobertura a serem usados. Consulte a documentação do istanbul para obter uma lista detalhada de todos os relatores. Consulte @types/istanbul-reporter para obter detalhes sobre as opções específicas do relator.

O relator tem três tipos diferentes:

Um único relator: { reporter: 'html' }
Vários relatores sem opções: { reporter: ['html', 'json'] }

Um único ou vários relatores com opções de relator:

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

Desde o Vitest 1.2.0, você também pode passar relatores de cobertura customizados. Consulte Guia - Relator de Cobertura Customizado para obter mais informações.

{
  reporter: [
    // Specify reporter using name of the NPM package
    '@vitest/custom-coverage-reporter',
    ['@vitest/custom-coverage-reporter', { someOption: true }],

    // Specify reporter using local path
    '/absolute/path/to/custom-reporter.cjs',
    ['/absolute/path/to/custom-reporter.cjs', { someOption: true }],
  ];
}

Desde o Vitest 0.31.0, você pode verificar seu relatório de cobertura na interface do Vitest: verifique Cobertura da Interface do Vitest para obter mais detalhes.

coverage.reportOnFailure 0.31.2+

Tipo: boolean
Padrão: false (desde o Vitest 0.34.0)
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.reportOnFailure, --coverage.reportOnFailure=false

Gera o relatório de cobertura mesmo quando os testes falham.

coverage.allowExternal

Tipo: boolean
Padrão: false
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.allowExternal, --coverage.allowExternal=false

Coleta a cobertura de arquivos fora da raiz (root) do projeto.

coverage.skipFull

Tipo: boolean
Padrão: false
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.skipFull, --coverage.skipFull=false

Não mostra arquivos com 100% de cobertura de declaração, ramificação e função.

coverage.thresholds

Opções para os limiares de cobertura.

coverage.thresholds.lines

Tipo: number
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.thresholds.lines=<number>

Limiar global para linhas. Consulte a documentação do istanbul para obter mais informações.

coverage.thresholds.functions

Tipo: number
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.thresholds.functions=<number>

Limiar global para funções. Consulte a documentação do istanbul para obter mais informações.

coverage.thresholds.branches

Tipo: number
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.thresholds.branches=<number>

Limiar global para ramificações. Consulte a documentação do istanbul para obter mais informações.

coverage.thresholds.statements

Tipo: number
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.thresholds.statements=<number>

Limiar global para declarações. Consulte a documentação do istanbul para obter mais informações.

coverage.thresholds.perFile

Tipo: boolean
Padrão: false
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.thresholds.perFile, --coverage.thresholds.perFile=false

Verifica os limiares por arquivo.

coverage.thresholds.autoUpdate

Tipo: boolean
Padrão: false
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.thresholds.autoUpdate=<boolean>

Atualiza todos os valores de limiar (lines, functions, branches e statements) para o arquivo de configuração quando a cobertura atual estiver acima dos limiares configurados. Esta opção ajuda a manter os limiares quando a cobertura é melhorada.

coverage.thresholds.100

Tipo: boolean
Padrão: false
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.thresholds.100, --coverage.thresholds.100=false

Define os limiares globais para 100. Atalho para --coverage.thresholds.lines 100 --coverage.thresholds.functions 100 --coverage.thresholds.branches 100 --coverage.thresholds.statements 100.

coverage.thresholds[glob-pattern]

Tipo: { statements?: number functions?: number branches?: number lines?: number }
Padrão: undefined
Disponível para provedores: 'v8' | 'istanbul'

Define os limiares para arquivos que correspondem ao padrão glob.

{
  coverage: {
    thresholds: {
      // Thresholds for all files
      functions: 95,
      branches: 70,

      // Thresholds for matching glob pattern
      'src/utils/**.ts': {
        statements: 95,
        functions: 90,
        branches: 85,
        lines: 80,
      },

      // Files matching this pattern will only have lines thresholds set.
      // Global thresholds are not inherited.
      '**/math.ts': {
        lines: 100,
      }
    }
  }
}

coverage.ignoreEmptyLines

Tipo: boolean
Padrão: false
Disponível para provedores: 'v8'
CLI: --coverage.ignoreEmptyLines=<boolean>

Ignora linhas vazias, comentários e outros códigos não relacionados ao tempo de execução, por exemplo, tipos Typescript.

Esta opção funciona apenas se o compilador usado remover comentários e outros códigos não relacionados ao tempo de execução do código transpilado. Por padrão, o Vite usa ESBuild que remove comentários e tipos Typescript de arquivos .ts, .tsx e .jsx.

Se você quiser aplicar o ESBuild a outros arquivos também, defina-os nas opções esbuild:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  esbuild: {
    // Transpile all files with ESBuild to remove comments from code coverage.
    include: ['**/*.js', '**/*.jsx', '**/*.mjs', '**/*.ts', '**/*.tsx'],
  },
  test: {
    coverage: {
      provider: 'v8',
      ignoreEmptyLines: true,
    },
  },
});

coverage.ignoreClassMethods

Tipo: string[]
Padrão: []
Disponível para provedores: 'istanbul'
CLI: --coverage.ignoreClassMethods=<method>

Define como um array de nomes de métodos de classe para ignorar na cobertura. Consulte a documentação do istanbul para obter mais informações.

coverage.watermarks

Tipo:

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

Padrão:

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

Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.watermarks.statements=50,80, --coverage.watermarks.branches=50,80

Watermarks para declarações, linhas, ramificações e funções. Consulte a documentação do istanbul para obter mais informações.

coverage.processingConcurrency

Tipo: boolean
Padrão: Math.min(20, os.availableParallelism?.() ?? os.cpus().length)
Disponível para provedores: 'v8' | 'istanbul'
CLI: --coverage.processingConcurrency=<number>

Limite de concorrência usado ao processar os resultados da cobertura.

coverage.customProviderModule

Tipo: string
Disponível para provedores: 'custom'
CLI: --coverage.customProviderModule=<path or module name>

Especifica o nome do módulo ou o caminho para o módulo do provedor de cobertura customizado. Consulte Guia - Provedor de Cobertura Customizado para obter mais informações.

testNamePattern*

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

Executa testes cujos nomes completos correspondam ao padrão especificado. Se você adicionar OnlyRunThis a esta propriedade, apenas os testes que contiverem a palavra OnlyRunThis no nome serão executados. Os demais serão ignorados.

import { expect, test } from 'vitest';

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

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

open*

Tipo: boolean
Padrão: !process.env.CI
CLI: --open, --open=false

Abre a interface do Vitest (Em desenvolvimento).

api

Tipo: boolean | number
Padrão: false
CLI: --api, --api.port, --api.host, --api.strictPort

Habilita um servidor para expor a API do Vitest. Quando definido como true, a porta padrão é 51204.

browser 0.29.4+

Tipo: { enabled?, name?, provider?, headless?, api?, slowHijackESM? }
Padrão: { enabled: false, headless: process.env.CI, api: 63315 }
CLI: --browser, --browser=<name>, --browser.name=chrome --browser.headless

Executa os testes do Vitest em um navegador. Por padrão, utiliza o WebdriverIO para executar os testes, mas pode ser configurado com a opção browser.provider.

NOTE

Leia mais sobre testes em um navegador real na página do guia.

WARNING

Este é um recurso experimental. Alterações que quebram a compatibilidade podem não seguir o SemVer. Recomenda-se fixar a versão do Vitest ao utilizá-lo.

browser.enabled

Tipo: boolean
Padrão: false
CLI: --browser, --browser.enabled=false

Habilita a execução de todos os testes em um navegador por padrão. Pode ser sobrescrito com a opção poolMatchGlobs.

browser.name

Tipo: string
CLI: --browser=safari

Executa todos os testes em um navegador específico. As opções possíveis variam dependendo do provedor:

webdriverio: firefox, chrome, edge, safari
playwright: firefox, webkit, chromium
custom: qualquer string que será passada para o provedor

browser.headless

Tipo: boolean
Padrão: process.env.CI
CLI: --browser.headless, --browser.headless=false

Executa o navegador no modo headless (sem interface gráfica). Se o Vitest estiver sendo executado em um ambiente de CI (Integração Contínua), essa opção é ativada por padrão.

browser.isolate

Tipo: boolean
Padrão: true
CLI: --browser.isolate, --browser.isolate=false

Executa cada teste em um iframe separado.

browser.fileParallelism 1.3.0+

Tipo: boolean
Padrão: o mesmo que fileParallelism
CLI: --browser.fileParallelism=false

Cria todos os iframes de teste simultaneamente para que sejam executados em paralelo.

Isso impede o uso de APIs interativas (como clicar ou passar o mouse) devido à presença de múltiplos iframes na tela. No entanto, se os testes não dependerem dessas APIs, a execução simultânea pode ser mais rápida.

TIP

Mesmo que o isolamento seja desativado por meio de browser.isolate=false, seus arquivos de teste ainda serão executados sequencialmente devido à natureza do executor de testes.

browser.api

Tipo: number | { port?, strictPort?, host? }
Padrão: 63315
CLI: --browser.api=63315, --browser.api.port=1234, --browser.api.host=example.com

Configura as opções para o servidor Vite que serve o código no navegador. Não afeta a opção test.api.

browser.provider

Tipo: 'webdriverio' | 'playwright' | string
Padrão: 'webdriverio'
CLI: --browser.provider=playwright

Define o provedor a ser utilizado na execução dos testes no navegador. O Vitest fornece dois provedores: webdriverio (padrão) e playwright. Provedores personalizados devem ser exportados usando a exportação default e ter o seguinte formato:

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

WARNING

Esta é uma API avançada para autores de bibliotecas. Se você precisa apenas executar testes em um navegador, use a opção browser.

browser.providerOptions 1.0.0+

Tipo: BrowserProviderOptions

Opções que serão passadas ao provedor durante a chamada de provider.initialize.

export default defineConfig({
  test: {
    browser: {
      providerOptions: {
        launch: {
          devtools: true,
        },
      },
    },
  },
});

TIP

Para ter uma melhor segurança de tipo ao usar provedores integrados, você pode adicionar um destes tipos (para o provedor que você está usando) ao campo compilerOptions.types do seu tsconfig:

json

{
  "compilerOptions": {
    "types": [
      "@vitest/browser/providers/webdriverio",
      "@vitest/browser/providers/playwright"
    ]
  }
}

browser.slowHijackESM 0.31.0+

Tipo: boolean
Padrão: false

Ao executar testes no Node.js, o Vitest pode usar sua própria resolução de módulo para simular módulos facilmente com a sintaxe vi.mock. No entanto, replicar a resolução de módulos ES no navegador é complexo, sendo necessário transformar os arquivos de origem antes que possam ser utilizados.

Esta opção não tem efeito em testes executados no Node.js.

Se você depende de espionar módulos ES com vi.spyOn, você pode habilitar este recurso experimental para permitir espionar as exportações do módulo.

browser.indexScripts 1.6.0+

Tipo: BrowserScript[]
Padrão: []

Scripts personalizados que devem ser injetados no HTML do índice antes que os iframes de teste sejam iniciados. Este documento HTML apenas configura os iframes e não importa o código em si.

O script src e content serão processados pelos plugins do Vite. O script deve ser fornecido no seguinte formato:

export interface BrowserScript {
  /**
   * Se "content" for fornecido e o tipo for "module", este será seu identificador.
   *
   * Se você estiver usando TypeScript, você pode adicionar a extensão `.ts` aqui, por exemplo.
   * @default `injected-${index}.js`
   */
  id?: string;
  /**
   * Conteúdo JavaScript a ser injetado. Esta string é processada pelos plugins do Vite se o tipo for "module".
   *
   * Você pode usar `id` para dar ao Vite uma dica sobre a extensão do arquivo.
   */
  content?: string;
  /**
   * Caminho para o script. Este valor é resolvido pelo Vite, então pode ser um módulo node ou um caminho de arquivo.
   */
  src?: string;
  /**
   * Se o script deve ser carregado assincronamente.
   */
  async?: boolean;
  /**
   * Tipo de script.
   * @default 'module'
   */
  type?: string;
}

browser.testerScripts 1.6.0+

Tipo: BrowserScript[]
Padrão: []

Scripts personalizados que devem ser injetados no HTML do testador antes que o ambiente de testes seja iniciado. Isso é útil para injetar os polyfills necessários para a implementação do Vitest no navegador. É recomendado usar setupFiles na maioria dos casos.

O script src e content serão processados pelos plugins do Vite.

clearMocks

Tipo: boolean
Padrão: false

Chama .mockClear() em todos os espiões (spies) antes de cada teste. Isso limpa o histórico da simulação, mas não redefine sua implementação para a padrão.

mockReset

Tipo: boolean
Padrão: false

Chama .mockReset() em todos os espiões (spies) antes de cada teste. Isso limpa o histórico da simulação e redefine sua implementação para uma função vazia (que retorna undefined).

restoreMocks

Tipo: boolean
Padrão: false

Chama .mockRestore() em todos os espiões (spies) antes de cada teste. Isso limpa o histórico da simulação e redefine sua implementação para a original.

unstubEnvs 0.26.0+

Tipo: boolean
Padrão: false

Chama vi.unstubAllEnvs antes de cada teste.

unstubGlobals 0.26.0+

Tipo: boolean
Padrão: false

Chama vi.unstubAllGlobals antes de cada teste.

testTransformMode 0.34.0+

Tipo: { web?, ssr? }

Determina o método de transformação para todos os módulos importados dentro de um teste que corresponde ao padrão glob. Por padrão, depende do ambiente. Por exemplo, testes em um ambiente JSDOM processarão todos os arquivos com a flag ssr: false, e testes com ambiente Node processam todos os módulos com ssr: true.

testTransformMode.ssr

Tipo: string[]
Padrão: []

Usa o fluxo de processamento de transformação SSR para todos os módulos dentro dos testes especificados.
Os plugins do Vite receberão a flag ssr: true ao processar esses arquivos.

testTransformMode.web

Tipo: string[]
Padrão: []

Primeiro, executa um fluxo de processamento de transformação normal (direcionado ao navegador) e, em seguida, realiza uma reescrita SSR para executar o código no Node.
Os plugins do Vite receberão a flag ssr: false ao processar esses arquivos.

snapshotFormat*

Tipo: PrettyFormatOptions

Opções de formatação para testes de snapshot. Essas opções são passadas para pretty-format.

TIP

Tenha em mente que o campo plugins neste objeto será ignorado.

Se você precisar estender o serializador de snapshot via plugins pretty-format, use a API expect.addSnapshotSerializer ou a opção snapshotSerializers.

snapshotSerializers* 1.3.0+

Tipo: string[]
Padrão: []

Uma lista de caminhos para módulos serializadores de snapshot para testes de snapshot, útil para adicionar serializadores de snapshot personalizados. Veja Serializador Personalizado para mais informações.

resolveSnapshotPath*

Tipo: (testPath: string, snapExtension: string) => string
Padrão: armazena arquivos de snapshot no diretório __snapshots__

Substitui o caminho padrão do snapshot. Por exemplo, para armazenar snapshots ao lado dos arquivos de teste:

import { defineConfig } from 'vitest/config';

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

allowOnly

Tipo: boolean
Padrão: !process.env.CI
CLI: --allowOnly, --allowOnly=false

Permite a execução de testes e suítes marcados como 'only' (apenas).

dangerouslyIgnoreUnhandledErrors*

Tipo: boolean
Padrão: false
CLI: --dangerouslyIgnoreUnhandledErrors --dangerouslyIgnoreUnhandledErrors=false

Ignora erros não tratados que possam ocorrer.

passWithNoTests*

Tipo: boolean
Padrão: false
CLI: --passWithNoTests, --passWithNoTests=false

O Vitest não falhará se nenhum teste for encontrado.

logHeapUsage

Tipo: boolean
Padrão: false
CLI: --logHeapUsage, --logHeapUsage=false

Mostra o uso de memória heap após cada teste. Útil para depurar vazamentos de memória.

css

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

Configura se o CSS deve ser processado. Quando excluídos, os arquivos CSS são substituídos por strings vazias, evitando o processamento subsequente. Os módulos CSS retornam um proxy para evitar impacto no tempo de execução.

css.include

Tipo: RegExp | RegExp[]
Padrão: []

Padrão RegExp para arquivos que devem retornar CSS e serão processados pelo fluxo de processamento do Vite.

TIP

Para processar todos os arquivos CSS, use /.+/.

css.exclude

Tipo: RegExp | RegExp[]
Padrão: []

Padrão RegExp para arquivos que retornarão um arquivo CSS vazio.

css.modules

Tipo: { classNameStrategy? }
Padrão: {}

css.modules.classNameStrategy

Tipo: 'stable' | 'scoped' | 'non-scoped'
Padrão: 'stable'

Se você decidir processar arquivos CSS, pode configurar se os nomes de classe dentro dos módulos CSS devem ser escopados (scoped). Você pode escolher uma das opções:

stable: os nomes de classe serão gerados como _${name}_${hashedFilename}, o que significa que a classe gerada permanecerá a mesma se o conteúdo do CSS for alterado, mas mudará se o nome do arquivo for modificado ou o arquivo for movido para outra pasta. Esta configuração é útil se você usar o recurso de snapshot.
scoped: os nomes de classe serão gerados como de costume, respeitando o método css.modules.generateScopeName, se você tiver um e o processamento CSS estiver habilitado. Por padrão, o nome do arquivo será gerado como _${name}_${hash}, onde o hash inclui o nome e o conteúdo do arquivo.
non-scoped: os nomes de classe não serão hasheados.

WARNING

Por padrão, o Vitest exporta um proxy, ignorando o processamento de módulos CSS. Se você depende de propriedades CSS em suas classes, é necessário habilitar o processamento CSS usando a opção include.

maxConcurrency

Tipo: number
Padrão: 5
CLI: --max-concurrency=10, --maxConcurrency=10

Define o número máximo de testes marcados com test.concurrent que podem ser executados simultaneamente.

Testes que excederem este limite serão enfileirados e executados assim que um espaço estiver disponível.

cache*

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

Use esta opção para desabilitar o recurso de cache. Atualmente, o Vitest armazena em cache os resultados dos testes para priorizar a execução dos testes mais demorados e dos que falharam.

sequence

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

Opções para configurar a ordem de execução dos testes.

Você pode fornecer opções de sequência através da CLI usando a notação de ponto:

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

sequence.sequencer*

Tipo: TestSequencerConstructor
Padrão: BaseSequencer

Uma classe customizada que define métodos para particionamento (sharding) e ordenação. Você pode estender BaseSequencer de vitest/node se precisar redefinir apenas um dos métodos sort e shard, mas ambos os métodos devem existir.

O particionamento ocorre antes da ordenação e somente se a opção --shard for especificada.

sequence.shuffle

Tipo: boolean | { files?, tests? }
Padrão: false
CLI: --sequence.shuffle, --sequence.shuffle=false

Se você deseja que os arquivos e testes sejam executados aleatoriamente, habilite esta opção ou use o argumento de CLI --sequence.shuffle.

O Vitest geralmente usa o cache para ordenar os testes, priorizando a execução dos testes mais demorados. Randomizar a ordem de execução pode eliminar esse ganho de desempenho, mas pode ser útil para identificar testes que dependem inadvertidamente de uma execução anterior.

sequence.shuffle.files 1.4.0+

Tipo: boolean
Padrão: false
CLI: --sequence.shuffle.files, --sequence.shuffle.files=false

Define se os arquivos devem ser executados em ordem aleatória. Tenha em mente que os testes mais demorados não serão iniciados primeiro se você habilitar esta opção.

sequence.shuffle.tests 1.4.0+

Tipo: boolean
Padrão: false
CLI: --sequence.shuffle.tests, --sequence.shuffle.tests=false

Define se os testes devem ser executados em ordem aleatória.

sequence.concurrent 0.32.2+

Tipo: boolean
Padrão: false
CLI: --sequence.concurrent, --sequence.concurrent=false

Para executar os testes em paralelo, habilite esta opção ou use o argumento de CLI --sequence.concurrent.

sequence.seed*

Tipo: number
Padrão: Date.now()
CLI: --sequence.seed=1000

Define a semente de randomização, usada quando os testes são executados em ordem aleatória.

sequence.hooks

Tipo: 'stack' | 'list' | 'parallel'
Padrão: 'parallel'
CLI: --sequence.hooks=<value>

Altera a ordem de execução dos hooks.

stack ordenará os hooks "after" em ordem inversa e os hooks "before" na ordem em que foram definidos.
list ordenará todos os hooks na ordem em que são definidos.
parallel executará os hooks em um único grupo em paralelo (os hooks nos suites pai ainda serão executados antes dos hooks do suite atual).

TIP

Esta opção não afeta onTestFinished. Ele sempre é chamado em ordem inversa.

sequence.setupFiles 0.29.3+

Tipo: 'list' | 'parallel'
Padrão: 'parallel'
CLI: --sequence.setupFiles=<value>

Altera a ordem de execução dos arquivos de configuração.

list executará os arquivos de configuração na ordem em que são definidos.
parallel executará os arquivos de configuração em paralelo.

typecheck

Opções para configurar o ambiente de teste de verificação de tipo.

typecheck.enabled 1.0.0+

Tipo: boolean
Padrão: false
CLI: --typecheck, --typecheck.enabled

Habilita a verificação de tipo junto com seus testes regulares.

typecheck.only 1.0.0+

Tipo: boolean
Padrão: false
CLI: --typecheck.only

Executa apenas testes de verificação de tipo, quando a verificação de tipo está habilitada. Ao usar a CLI, esta opção habilitará automaticamente a verificação de tipo.

typecheck.checker

Tipo: 'tsc' | 'vue-tsc' | string
Padrão: tsc

Define qual ferramenta usar para a verificação de tipo. O Vitest irá gerar um processo com parâmetros específicos para facilitar a análise, dependendo do verificador de tipo utilizado. O verificador deve implementar o mesmo formato de saída que tsc.

Você precisa ter o pacote correspondente instalado para usar o verificador de tipo:

tsc requer o pacote typescript
vue-tsc requer o pacote vue-tsc

Você também pode fornecer o caminho para um binário customizado ou o nome de um comando que produza a mesma saída que tsc --noEmit --pretty false.

typecheck.include

Tipo: string[]
Padrão: ['**/*.{test,spec}-d.?(c|m)[jt]s?(x)']

Padrão glob para arquivos que devem ser tratados como arquivos de teste.

typecheck.exclude

Tipo: string[]
Padrão: ['**/node_modules/**', '**/dist/**', '**/cypress/**', '**/.{idea,git,cache,output,temp}/**']

Padrão glob para arquivos que não devem ser tratados como arquivos de teste.

typecheck.allowJs

Tipo: boolean
Padrão: false

Verifica arquivos JS que possuem o comentário @ts-check. Se você já tiver habilitado essa opção no tsconfig, esta configuração não a substituirá.

typecheck.ignoreSourceErrors

Tipo: boolean
Padrão: false

Impede que o Vitest falhe se encontrar erros fora dos arquivos de teste. Isso não exibirá erros que não estejam relacionados aos testes.

Por padrão, se o Vitest encontrar um erro no código-fonte, o conjunto de testes falhará.

typecheck.tsconfig

Tipo: string
Padrão: Tenta encontrar o arquivo tsconfig.json mais próximo

Caminho para um arquivo tsconfig customizado, relativo à raiz do projeto.

slowTestThreshold*

Tipo: number
Padrão: 300
CLI: --slow-test-threshold=<number>, --slowTestThreshold=<number>

O número de milissegundos após o qual um teste é considerado lento e relatado como tal nos resultados.

chaiConfig 0.30.0+

Tipo: { includeStack?, showDiff?, truncateThreshold? }
Padrão: { includeStack: false, showDiff: true, truncateThreshold: 40 }

Equivalente à configuração do Chai.

chaiConfig.includeStack

Tipo: boolean
Padrão: false

Determina se o rastreamento de pilha é incluído na mensagem de erro de asserção. O valor padrão false suprime o rastreamento de pilha na mensagem de erro.

chaiConfig.showDiff

Tipo: boolean
Padrão: true

Determina se o sinalizador showDiff deve ser incluído nos AssertionErrors lançados. Se definido como false, sempre será false. Se definido como true, será verdadeiro quando a asserção tiver solicitado que uma diferença seja mostrada.

chaiConfig.truncateThreshold

Tipo: number
Padrão: 40

Define o limite de comprimento para valores reais e esperados em erros de asserção. Se este limite for excedido, por exemplo, para grandes estruturas de dados, o valor é substituído por algo como [ Array(3) ] ou { Object (prop1, prop2) }. Defina-o como 0 se você quiser desabilitar o truncamento completamente.

Esta opção de configuração afeta o truncamento de valores em títulos test.each e dentro da mensagem de erro de asserção.

bail 0.31.0+

Tipo: number
Padrão: 0
CLI: --bail=<value>

Interrompe a execução dos testes quando um determinado número de testes falhar.

Por padrão, o Vitest executará todos os seus casos de teste, mesmo que alguns deles falhem. Isso pode não ser desejado para compilações de CI onde você está interessado apenas em compilações 100% bem-sucedidas e gostaria de interromper a execução do teste o mais cedo possível quando ocorrerem falhas de teste. A opção bail pode ser usada para acelerar as execuções de CI, impedindo que ele execute mais testes quando ocorrerem falhas.

retry 0.32.3+

Tipo: number
Padrão: 0
CLI: --retry=<value>

Repete o teste um número determinado de vezes caso ele falhe.

onConsoleLog*

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

Handler customizado para console.log nos testes. Se você retornar false, o Vitest não imprimirá o log no console.

Pode ser útil para filtrar logs de bibliotecas de terceiros.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    onConsoleLog(log: string, type: 'stdout' | 'stderr'): boolean | void {
      return !(
        log === 'mensagem da biblioteca de terceiros' && type === 'stdout'
      );
    },
  },
});

onStackTrace* 1.0.0+

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

Aplica uma função de filtragem a cada frame no rastreamento de pilha ao lidar com erros. O primeiro argumento, error, é um objeto com as mesmas propriedades de um Error padrão, mas não é uma instância real.

Pode ser útil para filtrar frames de rastreamento de pilha de bibliotecas de terceiros.

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

export default defineConfig({
  test: {
    onStackTrace(error: Error, { file }: ParsedStack): boolean | void {
      // Se encontramos um ReferenceError, mostre a pilha inteira.
      if (error.name === 'ReferenceError') return;

      // Rejeitar todos os frames de bibliotecas de terceiros.
      if (file.includes('node_modules')) return false;
    },
  },
});

diff 0.34.5+

Tipo: string
CLI: --diff=<value>

Caminho para um arquivo de configuração de diff que será usado para gerar a interface de diff. Útil se você quiser personalizar a exibição de diff.

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',
  },
});

diff.truncateThreshold

Tipo: number
Padrão: 0

O comprimento máximo do resultado do diff a ser exibido. Diffs acima deste limite serão truncados. O truncamento não terá efeito com o valor padrão 0.

diff.truncateAnnotation

Tipo: string
Padrão: '... Diff result is truncated'

Anotação que é exibida no final do resultado do diff se ele for truncado.

diff.truncateAnnotationColor

Tipo: DiffOptionsColor = (arg: string) => string
Padrão: noColor = (string: string): string => string

Cor da anotação de truncamento. O padrão é a saída sem cor.

fakeTimers

Tipo: FakeTimerInstallOpts

Opções que o Vitest passará para @sinon/fake-timers ao usar vi.useFakeTimers().

fakeTimers.now

Tipo: number | Date
Padrão: Date.now()

Instala timers falsos com a época Unix especificada.

fakeTimers.toFake

Tipo: ('setTimeout' | 'clearTimeout' | 'setImmediate' | 'clearImmediate' | 'setInterval' | 'clearInterval' | 'Date' | 'nextTick' | 'hrtime' | 'requestAnimationFrame' | 'cancelAnimationFrame' | 'requestIdleCallback' | 'cancelIdleCallback' | 'performance' | 'queueMicrotask')[]
Padrão: ['setTimeout', 'clearTimeout', 'setImmediate', 'clearImmediate', 'setInterval', 'clearInterval', 'Date']

Um array com os nomes dos métodos globais e APIs a serem mockados.

Para mockar apenas setTimeout() e nextTick(), especifique esta propriedade como ['setTimeout', 'nextTick'].

Mockar nextTick não é suportado ao executar o Vitest dentro de node:child_process usando --pool=forks. NodeJS usa process.nextTick internamente em node:child_process e trava quando é mockado. Mockar nextTick é suportado ao executar o Vitest com --pool=threads.

fakeTimers.loopLimit

Tipo: number
Padrão: 10_000

O número máximo de timers que serão executados ao chamar vi.runAllTimers().

fakeTimers.shouldAdvanceTime

Tipo: boolean
Padrão: false

Instrui o @sinonjs/fake-timers a incrementar automaticamente o tempo mockado com base na variação do tempo real do sistema.

fakeTimers.advanceTimeDelta

Tipo: number
Padrão: 20

Relevante apenas quando usado com shouldAdvanceTime: true. Incrementa o tempo mockado em advanceTimeDelta ms a cada variação de advanceTimeDelta ms no tempo real do sistema.

fakeTimers.shouldClearNativeTimers

Tipo: boolean
Padrão: false

Instrui os timers falsos a limpar os timers "nativos" (ou seja, não mockados) delegando aos seus respectivos handlers. Estes não são limpos por padrão, levando a um comportamento potencialmente inesperado se os timers existirem antes de iniciar a sessão de timers falsos.

workspace* 1.1.0+

Tipo: string
CLI: --workspace=./file.js
Padrão: vitest.{workspace,projects}.{js,ts,json} próximo ao arquivo de configuração ou raiz

Caminho para um arquivo de configuração de workspace relativo a root.

isolate 1.1.0+

Tipo: boolean
Padrão: true
CLI: --no-isolate, --isolate=false

Executa testes em um ambiente isolado. Esta opção não terá efeito nos pools vmThreads e vmForks.

Desabilitar esta opção pode melhorar o desempenho se o seu código não depender de efeitos colaterais (o que geralmente ocorre em projetos com ambiente node).

TIP

Você pode desabilitar o isolamento para pools específicos usando a propriedade poolOptions.

includeTaskLocation 1.4.0+

Tipo: boolean
Padrão: false

Determina se a propriedade location deve ser incluída quando a API do Vitest recebe tarefas nos reporters. Se você tiver muitos testes, isso pode causar uma leve diminuição no desempenho.

A propriedade location tem valores column e line que correspondem à posição test ou describe no arquivo original.

TIP

Esta opção não tem efeito se você não usar código personalizado que dependa disso.

snapshotEnvironment 1.6.0+

Tipo: string

Caminho para uma implementação customizada do ambiente de snapshot. Isso é útil se você estiver executando seus testes em um ambiente que não suporta APIs do Node.js. Esta opção não tem nenhum efeito em um executor de navegador.

Este objeto deve ter a forma de SnapshotEnvironment e é usado para resolver e ler/escrever arquivos de snapshot:

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

Você pode estender o VitestSnapshotEnvironment padrão a partir do ponto de entrada vitest/snapshot se precisar sobrescrever apenas parte da API.

WARNING

Esta é uma opção de baixo nível e deve ser usada apenas para casos avançados onde você não tem acesso às APIs padrão do Node.js.

Se você só precisa configurar o recurso de snapshots, use as opções snapshotFormat ou resolveSnapshotPath.

Configurando o Vitest ​

include ​

exclude ​

includeSource ​

server 0.34.0+ ​

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 0.34.0+ ​

deps.optimizer.{mode}.enabled ​

deps.web 0.34.2+ ​

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 1.6.0+ ​

benchmark.compare 1.6.0+ ​

alias ​

globals ​

environment ​

environmentOptions ​

environmentMatchGlobs ​

poolMatchGlobs 0.29.4+ ​

update* ​

watch* ​

root ​

reporters* ​

outputFile* ​

pool* 1.0.0+ ​

threads* ​

forks* ​

vmThreads* ​

vmForks* ​

poolOptions* 1.0.0+ ​

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 1.1.0+ ​

maxWorkers 1.1.0+ ​

minWorkers 1.1.0+ ​

testTimeout ​

hookTimeout ​

teardownTimeout* ​

silent* ​

Configurando o Vitest

include

exclude

includeSource

server 0.34.0+

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 0.34.0+

deps.optimizer.{mode}.enabled

deps.web 0.34.2+

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 1.6.0+

benchmark.compare 1.6.0+

alias

globals

environment

environmentOptions

environmentMatchGlobs

poolMatchGlobs 0.29.4+

update*

watch*

root

reporters*

outputFile*

pool* 1.0.0+

threads*

forks*

vmThreads*

vmForks*

poolOptions* 1.0.0+

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 1.1.0+

maxWorkers 1.1.0+

minWorkers 1.1.0+

testTimeout

hookTimeout

teardownTimeout*

silent*