Vi

O Vitest fornece funções utilitárias para auxiliar você através do seu helper vi. Você pode acessá-lo globalmente (quando a configuração de globais está habilitada), ou importar de vitest:

import { vi } from 'vitest';

vi.advanceTimersByTime

Tipo: (ms: number) => Vitest
Funciona de forma similar a runAllTimers, mas finaliza após o tempo especificado em milissegundos. Por exemplo, o código abaixo registrará 1, 2, 3 sem lançar erros:
ts
```
let i = 0;
setInterval(() => console.log(++i), 50);

vi.advanceTimersByTime(150);
```

vi.advanceTimersByTimeAsync

Tipo: (ms: number) => Promise<Vitest>
Funciona de forma similar a runAllTimersAsync, mas finaliza após o tempo especificado em milissegundos. Isso incluirá timers definidos de forma assíncrona. Por exemplo, o código abaixo registrará 1, 2, 3 sem lançar erros:
ts
```
let i = 0;
setInterval(() => Promise.resolve().then(() => console.log(++i)), 50);

await vi.advanceTimersByTimeAsync(150);
```

vi.advanceTimersToNextTimer

Tipo: () => Vitest

Executará o próximo timer disponível. Útil para fazer asserções entre cada chamada de timer. Você pode encadear chamadas para gerenciar os timers.

let i = 0;
setInterval(() => console.log(++i), 50);

vi.advanceTimersToNextTimer() // log 1
  .advanceTimersToNextTimer() // log 2
  .advanceTimersToNextTimer(); // log 3

vi.advanceTimersToNextTimerAsync

Tipo: () => Promise<Vitest>

Executará o próximo timer disponível, mesmo que tenha sido definido assincronamente. Útil para fazer asserções entre cada chamada de timer. Você pode encadear chamadas para gerenciar os timers.

let i = 0;
setInterval(() => Promise.resolve().then(() => console.log(++i)), 50);

vi.advanceTimersToNextTimerAsync() // log 1
  .advanceTimersToNextTimerAsync() // log 2
  .advanceTimersToNextTimerAsync(); // log 3

vi.getTimerCount

Tipo: () => number
Retorna o número de timers pendentes.

vi.clearAllMocks

Chamará .mockClear() em todos os spies. Isso limpará o histórico de mock, mas não redefinirá sua implementação para a padrão.

vi.clearAllTimers

Remove todos os timers que estão agendados para serem executados. Esses timers nunca serão executados no futuro.

vi.dynamicImportSettled

Aguarda o carregamento de todas as importações dinâmicas. Útil se você tiver uma chamada síncrona que inicia a importação de um módulo, que você não pode aguardar de outra forma.

vi.fn

Tipo: (fn?: Function) => Mock
Cria um spy para uma função, mesmo que seja criado sem uma função. Cada vez que a função é invocada, ela armazena seus argumentos de chamada, retornos e instâncias. Além disso, você pode manipular seu comportamento com métodos. Se nenhuma função for fornecida, o mock retornará undefined ao ser invocado.
ts
```
const getApples = vi.fn(() => 0);

getApples();

expect(getApples).toHaveBeenCalled();
expect(getApples).toHaveReturnedWith(0);

getApples.mockReturnValueOnce(5);

const res = getApples();
expect(res).toBe(5);
expect(getApples).toHaveNthReturnedWith(2, 5);
```

vi.getMockedSystemTime

Tipo: () => Date | null
Retorna a data mockada atual que foi definida usando setSystemTime. Se a data não estiver mockada, retornará null.

vi.getRealSystemTime

Tipo: () => number
Ao usar vi.useFakeTimers, as chamadas a Date.now são mockadas. Se você precisar obter o tempo real em milissegundos, você pode chamar esta função.

vi.hoisted

Tipo: <T>(factory: () => T) => T
Versão: Desde Vitest 0.31.0
Todas as declarações import estáticas em módulos ES são içadas para o topo do arquivo, então qualquer código que seja definido antes das importações será realmente executado após a avaliação das importações.
No entanto, pode ser útil executar alguma operação, como mockar datas, antes de importar um módulo.
Para contornar essa limitação, você pode reescrever importações estáticas em dinâmicas da seguinte forma:
diff
```
callFunctionWithSideEffect()
- import { value } from './some/module.ts'
+ const { value } = await import('./some/module.ts')
```
Ao executar vitest, você pode fazer isso automaticamente usando o método vi.hoisted.
diff
```
- callFunctionWithSideEffect()
import { value } from './some/module.ts'
+ vi.hoisted(() => callFunctionWithSideEffect())
```
Este método retorna o valor que foi retornado da factory. Você pode usar esse valor em suas factories vi.mock se precisar de acesso fácil a variáveis definidas localmente:
ts
```
import { expect, vi } from 'vitest';
import { originalMethod } from './path/to/module.js';

const { mockedMethod } = vi.hoisted(() => {
  return { mockedMethod: vi.fn() };
});

vi.mock('./path/to/module.js', () => {
  return { originalMethod: mockedMethod };
});

mockedMethod.mockReturnValue(100);
expect(originalMethod()).toBe(100);
```

vi.mock

Tipo: (path: string, factory?: () => unknown) => void
Substitui todos os módulos importados do path fornecido com outro módulo. Você pode usar aliases Vite configurados dentro de um path. A chamada para vi.mock é içada, então não importa onde você a chama. Ela sempre será executada antes de todas as importações. Se você precisar referenciar algumas variáveis fora de seu escopo, você pode defini-las em vi.hoisted e referenciá-las em vi.mock.
WARNING
vi.mock funciona apenas para módulos que foram importados com a palavra-chave import. Não funciona com require.
O Vitest analisa estaticamente seus arquivos para içar vi.mock. Isso significa que você não pode usar vi que não foi importado diretamente do pacote vitest. Para corrigir isso, sempre use vi.mock com vi importado de vitest, ou habilite a opção de configuração globals.
WARNING
Mockar módulos não é atualmente suportado no modo navegador. Você pode acompanhar este recurso na issue no GitHub.
Se factory for definido, todas as importações retornarão seu resultado. O Vitest chama a factory apenas uma vez e armazena o resultado em cache para todas as importações subsequentes até que vi.unmock ou vi.doUnmock seja chamado.
Ao contrário do jest, a factory pode ser assíncrona, então você pode usar vi.importActual ou um auxiliar, recebido como o primeiro argumento, dentro para obter o módulo original.
ts
```
vi.mock('./path/to/module.js', async importOriginal => {
  const mod = await importOriginal();
  return {
    ...mod,
    // substitui algumas exportações
    namedExport: vi.fn(),
  };
});
```
WARNING
vi.mock é içado (em outras palavras, movido) para o topo do arquivo. Isso significa que sempre que você o escreve (seja dentro de beforeEach ou test), ele será realmente chamado antes disso.
Isso significa que você não pode usar variáveis definidas fora da factory.
Se precisar usar variáveis dentro da factory, tente vi.doMock. Ele funciona da mesma forma, mas não é içado. Tenha cuidado, pois ele só mocka importações subsequentes.
Você também pode referenciar variáveis definidas pelo método vi.hoisted se ele foi declarado antes de vi.mock:
ts
```
import { namedExport } from './path/to/module.js';

const mocks = vi.hoisted(() => {
  return {
    namedExport: vi.fn(),
  };
});

vi.mock('./path/to/module.js', () => {
  return {
    namedExport: mocks.namedExport,
  };
});

vi.mocked(namedExport).mockReturnValue(100);

expect(namedExport()).toBe(100);
expect(namedExport).toBe(mocks.namedExport);
```
WARNING
Se você estiver mockando um módulo com exportação padrão (default export), você precisará fornecer uma chave default dentro do objeto da função de factory retornada. Esta é uma ressalva específica dos módulos ES, portanto a documentação do jest pode ser diferente, pois o jest usa módulos CommonJS. Por exemplo,
ts
```
vi.mock('./path/to/module.js', () => {
  return {
    default: { myDefaultKey: vi.fn() },
    namedExport: vi.fn(),
    // etc...
  };
});
```
Se houver uma pasta __mocks__ junto com um arquivo que você está mockando, e a factory não for fornecida, o Vitest tentará encontrar um arquivo com o mesmo nome na subpasta __mocks__ e usá-lo como um módulo real. Se você estiver mockando uma dependência, o Vitest tentará encontrar uma pasta __mocks__ na raiz do projeto (o padrão é process.cwd()). Você pode dizer ao Vitest onde as dependências estão localizadas através da opção de configuração deps.moduleDirectories.
Por exemplo, você tem esta estrutura de arquivos:
```
- __mocks__
  - axios.js
- src
  __mocks__
    - increment.js
  - increment.js
- tests
  - increment.test.js
```
Se você chamar vi.mock em um arquivo de teste sem uma factory fornecida, ele encontrará um arquivo na pasta __mocks__ para usar como um módulo:
ts
```
// increment.test.js
import { vi } from 'vitest';

// axios é uma exportação padrão de `__mocks__/axios.js`
import axios from 'axios';

// increment é uma exportação nomeada de `src/__mocks__/increment.js`
import { increment } from '../increment.js';

vi.mock('axios');
vi.mock('../increment.js');

axios.get(`/apples/${increment(1)}`);
```
WARNING
Tenha cuidado, pois se você não chamar vi.mock, os módulos não são mockados automaticamente. Para replicar o comportamento de automocking do Jest, você pode chamar vi.mock para cada módulo necessário dentro de setupFiles.
Se não houver uma pasta __mocks__ ou uma factory fornecida, o Vitest importará o módulo original e fará o auto-mock de todas as suas exportações. Para as regras aplicadas, veja algoritmo.

vi.doMock

Tipo: (path: string, factory?: () => unknown) => void
O mesmo que vi.mock, mas não é içado para o topo do arquivo, então você pode referenciar variáveis no escopo do arquivo global. A próxima importação dinâmica do módulo será mockada. Isso não fará mock de módulos que já foram importados.

// ./increment.js
export function increment(number) {
  return number + 1;
}

import { beforeEach, test } from 'vitest';
import { increment } from './increment.js';

// o módulo não é mockado, porque vi.doMock ainda não foi chamado
increment(1) === 2;

let mockedIncrement = 100;

beforeEach(() => {
  // você pode acessar variáveis dentro de uma factory
  vi.doMock('./increment.js', () => ({ increment: () => ++mockedIncrement }));
});

test('importar o próximo módulo importa o módulo mockado', async () => {
  // a importação original NÃO FOI MOCKADA, porque vi.doMock é avaliado DEPOIS das importações
  expect(increment(1)).toBe(2);
  const { increment: mockedIncrement } = await import('./increment.js');
  // a nova importação dinâmica retorna o módulo mockado
  expect(mockedIncrement(1)).toBe(101);
  expect(mockedIncrement(1)).toBe(102);
  expect(mockedIncrement(1)).toBe(103);
});

vi.mocked

Tipo: <T>(obj: T, deep?: boolean) => MaybeMockedDeep<T>
Tipo: <T>(obj: T, options?: { partial?: boolean; deep?: boolean }) => MaybePartiallyMockedDeep<T>
Utilitário de tipos para TypeScript. Na realidade, apenas retorna o objeto que foi passado.
Quando partial é true, ele esperará um Partial<T> como um valor de retorno.
ts
```
import example from './example.js';

vi.mock('./example.js');

test('1+1 é igual a 2', async () => {
  vi.mocked(example.calc).mockRestore();

  const res = example.calc(1, '+', 1);

  expect(res).toBe(2);
});
```

vi.importActual

Tipo: <T>(path: string) => Promise<T>
Importa o módulo, ignorando todas as verificações se ele deve ser mockado. Pode ser útil se você quiser mockar o módulo parcialmente.
ts
```
vi.mock('./example.js', async () => {
  const axios = await vi.importActual('./example.js');

  return { ...axios, get: vi.fn() };
});
```

vi.importMock

Tipo: <T>(path: string) => Promise<MaybeMockedDeep<T>>
Importa um módulo com todas as suas propriedades (incluindo propriedades aninhadas) mockadas. Segue as mesmas regras que vi.mock segue. Para as regras aplicadas, veja algoritmo.

vi.resetAllMocks

Chamará .mockReset() em todos os spies. Isso limpará o histórico de mock e redefinirá sua implementação para uma função vazia (retornará undefined).

vi.resetConfig

Tipo: RuntimeConfig
Se vi.setConfig foi chamado antes, isso restaurará a configuração original.

vi.resetModules

Tipo: () => Vitest

Redefine o registro de módulos, limpando o cache de todos os módulos. Isso permitirá a reavaliação dos módulos ao serem reimportados. As importações de nível superior não podem ser reavaliadas. Pode ser útil para isolar módulos quando há conflito de estado local entre testes.

import { vi } from 'vitest';

import { data } from './data.js'; // Não será reavaliado beforeEach test

beforeEach(() => {
  vi.resetModules();
});

test('alterar estado', async () => {
  const mod = await import('./some/path.js'); // Será reavaliado
  mod.changeLocalState('new value');
  expect(mod.getLocalState()).toBe('new value');
});

test('módulo tem estado antigo', async () => {
  const mod = await import('./some/path.js'); // Será reavaliado
  expect(mod.getLocalState()).toBe('old value');
});

WARNING

Não redefine o registro de mocks. Para limpar o registro de mocks, use vi.unmock ou vi.doUnmock.

vi.restoreAllMocks

Chamará .mockRestore() em todos os spies. Isso limpará o histórico de mock e redefinirá sua implementação para a original.

vi.stubEnv

Tipo: (name: string, value: string) => Vitest
Versão: Desde Vitest 0.26.0
Define o valor da variável de ambiente em process.env e import.meta.env. Você pode restaurar seu valor chamando vi.unstubAllEnvs.

import { vi } from 'vitest';

// `process.env.NODE_ENV` e `import.meta.env.NODE_ENV`
// são "development" antes de chamar "vi.stubEnv"

vi.stubEnv('NODE_ENV', 'production');

process.env.NODE_ENV === 'production';
import.meta.env.NODE_ENV === 'production';
// não altera outros envs
import.meta.env.MODE === 'development';

TIP

Você também pode alterar o valor simplesmente atribuindo-o, mas você não poderá usar vi.unstubAllEnvs para restaurar o valor anterior:

import.meta.env.MODE = 'test';

vi.unstubAllEnvs

Tipo: () => Vitest
Versão: Disponível desde o Vitest 0.26.0
Restaura todos os valores de import.meta.env e process.env que foram modificados com vi.stubEnv. Na primeira chamada, o Vitest armazena o valor original e o mantém até que unstubAllEnvs seja chamado novamente.

import { vi } from 'vitest';

// `process.env.NODE_ENV` e `import.meta.env.NODE_ENV`
// são "development" antes de chamar stubEnv

vi.stubEnv('NODE_ENV', 'production');

process.env.NODE_ENV === 'production';
import.meta.env.NODE_ENV === 'production';

vi.stubEnv('NODE_ENV', 'staging');

process.env.NODE_ENV === 'staging';
import.meta.env.NODE_ENV === 'staging';

vi.unstubAllEnvs();

// restaura para o valor armazenado antes da primeira chamada de "stubEnv"
process.env.NODE_ENV === 'development';
import.meta.env.NODE_ENV === 'development';

vi.stubGlobal

Tipo: (name: string | number | symbol, value: unknown) => Vitest
Altera o valor de uma variável global. Você pode restaurar o valor original chamando vi.unstubAllGlobals.

import { vi } from 'vitest';

// `innerWidth` é "0" antes de chamar stubGlobal

vi.stubGlobal('innerWidth', 100);

innerWidth === 100;
globalThis.innerWidth === 100;
// se você estiver usando jsdom ou happy-dom
window.innerWidth === 100;

TIP

Você também pode alterar o valor simplesmente atribuindo-o a globalThis ou window (se você estiver usando o ambiente jsdom ou happy-dom), mas não poderá usar vi.unstubAllGlobals para restaurar o valor original:

globalThis.innerWidth = 100;
// se você estiver usando jsdom ou happy-dom
window.innerWidth = 100;

vi.unstubAllGlobals

Tipo: () => Vitest
Versão: Disponível desde o Vitest 0.26.0
Restaura todos os valores globais em globalThis e global (e window, top, self e parent, se você estiver usando o ambiente jsdom ou happy-dom) que foram alterados com vi.stubGlobal. Na primeira vez que é chamado, o Vitest armazena o valor original e o mantém até que unstubAllGlobals seja chamado novamente.

import { vi } from 'vitest';

const Mock = vi.fn();

// IntersectionObserver é "undefined" antes de chamar "stubGlobal"

vi.stubGlobal('IntersectionObserver', Mock);

IntersectionObserver === Mock;
global.IntersectionObserver === Mock;
globalThis.IntersectionObserver === Mock;
// se você estiver usando jsdom ou happy-dom
window.IntersectionObserver === Mock;

vi.unstubAllGlobals();

globalThis.IntersectionObserver === undefined;
'IntersectionObserver' in globalThis === false;
// lança ReferenceError, porque não está definido
IntersectionObserver === undefined;

vi.runAllTicks

Tipo: () => Vitest
Executa cada microtarefa que foi enfileirada por process.nextTick. Isso também executará todas as microtarefas que elas mesmas agendaram.

vi.runAllTimers

Tipo: () => Vitest
Este método executa todos os timers iniciados até que a fila de timers esteja vazia. Isso significa que todos os timers chamados durante runAllTimers serão executados. Se houver um intervalo infinito, um erro será lançado após 10.000 tentativas de execução. Por exemplo, isso registrará 1, 2, 3:
ts
```
let i = 0;
setTimeout(() => console.log(++i));
const interval = setInterval(() => {
  console.log(++i);
  if (i === 3) clearInterval(interval);
}, 50);

vi.runAllTimers();
```

vi.runAllTimersAsync

Tipo: () => Promise<Vitest>
Este método executa assincronamente todos os timers iniciados até que a fila de timers esteja vazia. Isso significa que cada timer chamado durante runAllTimersAsync será executado, mesmo timers assíncronos. Se houver um intervalo infinito, um erro será lançado após 10.000 tentativas de execução. Por exemplo, isso registrará result:
ts
```
setTimeout(async () => {
  console.log(await Promise.resolve('result'));
}, 100);

await vi.runAllTimersAsync();
```

vi.runOnlyPendingTimers

Tipo: () => Vitest
Este método executa cada timer que foi iniciado após a chamada de vi.useFakeTimers(). Ele não executará nenhum timer que foi iniciado durante sua execução. Por exemplo, isso registrará apenas 1:
ts
```
let i = 0;
setInterval(() => console.log(++i), 50);

vi.runOnlyPendingTimers();
```

vi.runOnlyPendingTimersAsync

Tipo: () => Promise<Vitest>

Este método executa assincronamente cada timer que foi iniciado após a chamada de vi.useFakeTimers(), mesmo os assíncronos. Ele não executará nenhum timer que foi iniciado durante sua execução. Por exemplo, isso registrará 2, 3, 3, 1:

setTimeout(() => {
  console.log(1);
}, 100);
setTimeout(() => {
  Promise.resolve().then(() => {
    console.log(2);
    setInterval(() => {
      console.log(3);
    }, 40);
  });
}, 10);

await vi.runOnlyPendingTimersAsync();

vi.setSystemTime

Tipo: (date: string | number | Date) => void
Define a data atual para a data especificada. Todas as chamadas a Date retornarão esta data.
Útil se você precisar testar algo que dependa da data atual - por exemplo, chamadas de luxon dentro do seu código.
ts
```
const date = new Date(1998, 11, 19);

vi.useFakeTimers();
vi.setSystemTime(date);

expect(Date.now()).toBe(date.valueOf());

vi.useRealTimers();
```

vi.setConfig

Tipo: RuntimeConfig
Atualiza a configuração para o arquivo de teste atual. Você só pode alterar os valores que são usados ao executar os testes.

vi.spyOn

Tipo: <T, K extends keyof T>(object: T, method: K, accessType?: 'get' | 'set') => MockInstance

Cria um espião (spy) em um método ou getter/setter de um objeto.

let apples = 0;
const cart = {
  getApples: () => 13,
};

const spy = vi.spyOn(cart, 'getApples').mockImplementation(() => apples);
apples = 1;

expect(cart.getApples()).toBe(1);

expect(spy).toHaveBeenCalled();
expect(spy).toHaveReturnedWith(1);

vi.stubGlobal

Tipo: (key: keyof globalThis & Window, value: any) => Vitest
Define um valor para uma variável global. Se você estiver usando jsdom ou happy-dom, também define o valor no objeto window.
Leia mais na seção "Mocking Globals" (Simulação de Globais).

vi.unmock

Tipo: (path: string) => void
Remove o módulo do registro de mocks. Todas as chamadas para importar retornarão o módulo original, mesmo que ele tenha sido mockado antes. Esta chamada é elevada (hoisted) para o topo do arquivo, portanto, ela só removerá o mock de módulos que foram definidos em setupFiles, por exemplo.

vi.doUnmock

Tipo: (path: string) => void
O mesmo que vi.unmock, mas não é elevado para o topo do arquivo. A próxima importação do módulo importará o módulo original em vez do módulo mockado. Isso não removerá o mock de módulos importados anteriormente.

// ./increment.js
export function increment(number) {
  return number + 1;
}

import { increment } from './increment.js';

// increment já está mockado, porque vi.mock é elevado
increment(1) === 100;

// isso é elevado, e a fábrica é chamada antes da importação na linha 1
vi.mock('./increment.js', () => ({ increment: () => 100 }));

// todas as chamadas são mockadas, e `increment` sempre retorna 100
increment(1) === 100;
increment(30) === 100;

// isso não é elevado, então outra importação retornará o módulo não mockado
vi.doUnmock('./increment.js');

// isso AINDA retorna 100, porque `vi.doUnmock` não reavalia um módulo
increment(1) === 100;
increment(30) === 100;

// a próxima importação não é mockada, agora `increment` é a função original que retorna count + 1
const { increment: unmockedIncrement } = await import('./increment.js');

unmockedIncrement(1) === 2;
unmockedIncrement(30) === 31;

vi.useFakeTimers

Tipo: () => Vitest
Para habilitar a simulação de timers (timers falsos), você precisa chamar este método. Ele envolverá todas as chamadas subsequentes para timers (como setTimeout, setInterval, clearTimeout, clearInterval, nextTick, setImmediate, clearImmediate e Date), até que vi.useRealTimers() seja chamado.
A simulação de nextTick não é suportada ao executar o Vitest dentro de node:child_process usando --no-threads. O NodeJS usa process.nextTick internamente em node:child_process e trava quando é mockado. A simulação de nextTick é suportada ao executar o Vitest com --threads.
A implementação é baseada internamente em @sinonjs/fake-timers.
TIP
Desde a versão 0.35.0, vi.useFakeTimers() não simula mais automaticamente process.nextTick. Ele ainda pode ser simulado especificando a opção no argumento toFake: vi.useFakeTimers({ toFake: ['nextTick'] }).

vi.isFakeTimers

Tipo: () => boolean
Versão: Disponível desde o Vitest 0.34.5
Retorna true se os timers falsos estiverem habilitados.

vi.useRealTimers

Tipo: () => Vitest
Após o uso de timers simulados, você pode chamar este método para restaurar os timers para suas implementações originais. Todos os timers que foram executados antes não serão restaurados.

vi.waitFor

Tipo: <T>(callback: WaitForCallback<T>, options?: number | WaitForOptions) => Promise<T>
Versão: Disponível desde o Vitest 0.34.5
Aguarda até que o callback seja executado com sucesso. Se o callback lançar um erro ou retornar uma promise rejeitada, a função continuará aguardando até que a execução seja bem-sucedida ou o tempo limite seja atingido.
Isto é muito útil quando se precisa aguardar a conclusão de uma ação assíncrona, como ao iniciar um servidor e esperar que ele esteja pronto.

import { expect, test, vi } from 'vitest';
import { createServer } from './server.js';

test('Server started successfully', async () => {
  const server = createServer();

  await vi.waitFor(
    () => {
      if (!server.isReady) throw new Error('Server not started');

      console.log('Server started');
    },
    {
      timeout: 500, // o padrão é 1000
      interval: 20, // o padrão é 50
    }
  );
  expect(server.isReady).toBe(true);
});

Funciona também para callbacks assíncronos

// @vitest-environment jsdom

import { expect, test, vi } from 'vitest';
import { getDOMElementAsync, populateDOMAsync } from './dom.js';

test('Element exists in a DOM', async () => {
  // começa a popular o DOM
  populateDOMAsync();

  const element = await vi.waitFor(
    async () => {
      // tenta obter o elemento até que ele exista
      const element = (await getDOMElementAsync()) as HTMLElement | null;
      expect(element).toBeTruthy();
      expect(element.dataset.initialized).toBeTruthy();
      return element;
    },
    {
      timeout: 500, // o padrão é 1000
      interval: 20, // o padrão é 50
    }
  );
  expect(element).toBeInstanceOf(HTMLElement);
});

Se vi.useFakeTimers for usado, vi.waitFor chama automaticamente vi.advanceTimersByTime(interval) em cada callback de verificação.

vi.waitUntil

Tipo: <T>(callback: WaitUntilCallback<T>, options?: number | WaitUntilOptions) => Promise<T>
Versão: Disponível desde o Vitest 0.34.5

Isso é semelhante a vi.waitFor, mas se o callback lançar algum erro, a execução será interrompida imediatamente e uma mensagem de erro é recebida. Se o callback retornar um valor falso, a próxima verificação continuará até que um valor verdadeiro seja retornado. Isso é útil quando você precisa aguardar a existência de algo antes de prosseguir.

Veja o exemplo abaixo. Pode-se usar vi.waitUntil para aguardar até que o elemento apareça na página e, em seguida, podemos fazer algo com o elemento.

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

test('Element render correctly', async () => {
  const element = await vi.waitUntil(() => document.querySelector('.element'), {
    timeout: 500, // o padrão é 1000
    interval: 20, // o padrão é 50
  });

  // faça algo com o elemento
  expect(element.querySelector('.element-child')).toBeTruthy();
});

Vi ​

vi.advanceTimersByTime ​

vi.advanceTimersByTimeAsync ​

vi.advanceTimersToNextTimer ​

vi.advanceTimersToNextTimerAsync ​

vi.getTimerCount ​

vi.clearAllMocks ​

vi.clearAllTimers ​

vi.dynamicImportSettled ​

vi.fn ​

vi.getMockedSystemTime ​

vi.getRealSystemTime ​

vi.hoisted ​

vi.mock ​

vi.doMock ​

vi.mocked ​

vi.importActual ​

vi.importMock ​

vi.resetAllMocks ​

vi.resetConfig ​

vi.resetModules ​

vi.restoreAllMocks ​

vi.stubEnv ​

vi.unstubAllEnvs ​

vi.stubGlobal ​

vi.unstubAllGlobals ​

vi.runAllTicks ​

vi.runAllTimers ​

vi.runAllTimersAsync ​

vi.runOnlyPendingTimers ​

vi.runOnlyPendingTimersAsync ​

vi.setSystemTime ​

vi.setConfig ​

vi.spyOn ​

vi.stubGlobal ​

vi.unmock ​

vi.doUnmock ​

vi.useFakeTimers ​

vi.isFakeTimers ​

vi.useRealTimers ​

vi.waitFor ​

vi.waitUntil ​

Vi

vi.advanceTimersByTime

vi.advanceTimersByTimeAsync

vi.advanceTimersToNextTimer

vi.advanceTimersToNextTimerAsync

vi.getTimerCount

vi.clearAllMocks

vi.clearAllTimers

vi.dynamicImportSettled

vi.fn

vi.getMockedSystemTime

vi.getRealSystemTime

vi.hoisted

vi.mock

vi.doMock

vi.mocked

vi.importActual

vi.importMock

vi.resetAllMocks

vi.resetConfig

vi.resetModules

vi.restoreAllMocks

vi.stubEnv

vi.unstubAllEnvs

vi.stubGlobal

vi.unstubAllGlobals

vi.runAllTicks

vi.runAllTimers

vi.runAllTimersAsync

vi.runOnlyPendingTimers

vi.runOnlyPendingTimersAsync

vi.setSystemTime

vi.setConfig

vi.spyOn

vi.stubGlobal

vi.unmock

vi.doUnmock

vi.useFakeTimers

vi.isFakeTimers

vi.useRealTimers

vi.waitFor

vi.waitUntil