Vi

Vitest stellt Hilfsfunktionen über seine vi-Funktion bereit. Du kannst global darauf zugreifen (wenn die Globaleinstellungen aktiviert sind) oder sie von vitest importieren:

import { vi } from 'vitest';

vi.advanceTimersByTime

Typ: (ms: number) => Vitest
Funktioniert ähnlich wie runAllTimers, wird aber nach der angegebenen Zeit in Millisekunden beendet. Das folgende Beispiel gibt 1, 2, 3 aus und löst keinen Fehler aus:
ts
```
let i = 0;
setInterval(() => console.log(++i), 50);

vi.advanceTimersByTime(150);
```

vi.advanceTimersByTimeAsync

Typ: (ms: number) => Promise<Vitest>
Funktioniert ähnlich wie runAllTimersAsync, wird aber nach der angegebenen Zeit in Millisekunden beendet. Dies schließt asynchron gesetzte Timer ein. Das folgende Beispiel gibt 1, 2, 3 aus und löst keinen Fehler aus:
ts
```
let i = 0;
setInterval(() => Promise.resolve().then(() => console.log(++i)), 50);

await vi.advanceTimersByTimeAsync(150);
```

vi.advanceTimersToNextTimer

Typ: () => Vitest

Führt den nächsten verfügbaren Timer aus. Nützlich für Assertions zwischen den Timer-Aufrufen. Du kannst Aufrufe verketten, um Timer selbst zu steuern.

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

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

vi.advanceTimersToNextTimerAsync

Typ: () => Promise<Vitest>

Führt den nächsten verfügbaren Timer aus, auch wenn er asynchron gesetzt wurde. Nützlich für Assertions zwischen den Timer-Aufrufen. Du kannst Aufrufe verketten, um Timer selbst zu steuern.

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

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

vi.getTimerCount

Typ: () => number
Gibt die Anzahl der ausstehenden Timer zurück.

vi.clearAllMocks

Ruft für alle Spione .mockClear() auf. Dies löscht die Mock-Historie, setzt aber die Implementierung nicht auf den Standardwert zurück.

vi.clearAllTimers

Entfernt alle Timer, die zur Ausführung vorgesehen sind. Diese Timer werden dann nie ausgeführt.

vi.dynamicImportSettled

Wartet, bis alle dynamischen Importe abgeschlossen sind. Nützlich, wenn ein synchroner Aufruf vorhanden ist, der einen Modulimport initiiert, auf den man sonst nicht warten könnte.

vi.fn

Typ: (fn?: Function) => Mock
Erstellt einen Spion für eine Funktion. Kann auch ohne Funktion initialisiert werden. Bei jedem Aufruf speichert die Funktion ihre Argumente, Rückgabewerte und Instanzen. Außerdem kann man ihr Verhalten mit Methoden manipulieren. Wird keine Funktion übergeben, gibt der Mock bei Aufruf undefined zurück.
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

Typ: () => Date | null
Gibt die aktuell gemockte Zeit zurück, die mit setSystemTime gesetzt wurde. Wenn die Zeit nicht gemockt wurde, wird null zurückgegeben.

vi.getRealSystemTime

Typ: () => number
Wenn vi.useFakeTimers aktiv ist, werden Date.now-Aufrufe gemockt. Wenn die aktuelle Zeit in Millisekunden benötigt wird, kann diese Funktion aufgerufen werden.

vi.hoisted

Typ: <T>(factory: () => T) => T
Version: Seit Vitest 0.31.0
In ES-Modulen werden alle statischen import-Anweisungen an den Anfang der Datei verschoben (hoisted), wodurch Code, der vor den Importen definiert ist, erst nach der Auswertung der Importe ausgeführt wird.
Es kann jedoch hilfreich sein, einige Nebeneffekte, wie das Mocken von Datumsangaben, vor dem Importieren eines Moduls aufzurufen.
Um diese Einschränkung zu überwinden, können statische Importe in dynamische umgeschrieben werden, wie hier:
diff
```
callFunctionWithSideEffect()
- import { value } from './some/module.ts'
+ const { value } = await import('./some/module.ts')
```
Bei der Ausführung von vitest kann dies automatisch erfolgen, indem die vi.hoisted-Methode verwendet wird.
diff
```
- callFunctionWithSideEffect()
import { value } from './some/module.ts'
+ vi.hoisted(() => callFunctionWithSideEffect())
```
Diese Methode gibt den Rückgabewert der Factory zurück. Dieser Wert kann in den vi.mock-Factories verwendet werden, wenn ein einfacher Zugriff auf lokal definierte Variablen benötigt wird:
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

Typ: (path: string, factory?: () => unknown) => void
Ersetzt alle Importe des Moduls mit dem angegebenen path durch ein anderes Modul. Es können konfigurierte Vite-Aliase innerhalb eines Pfads verwendet werden. Der Aufruf von vi.mock wird nach oben verschoben (hoisted), daher ist es unerheblich, wo er aufgerufen wird. Er wird immer vor allen Importen ausgeführt. Wenn auf Variablen außerhalb ihres Gültigkeitsbereichs zugegriffen werden muss, können sie innerhalb von vi.hoisted definiert und innerhalb von vi.mock referenziert werden.
WARNING
vi.mock funktioniert nur für Module, die mit dem Schlüsselwort import importiert wurden. Es funktioniert nicht mit require.
Vitest analysiert deine Dateien statisch, um vi.mock nach oben zu verschieben (hoist). Dies bedeutet, dass kein vi verwendet werden kann, das nicht direkt aus dem vitest-Paket importiert wurde (z. B. aus einer Hilfsdatei). Um dies zu beheben, verwende immer vi.mock mit vi, das von vitest importiert wurde, oder aktiviere die Konfigurationsoption globals.
WARNING
Das Mocken von Modulen wird im Browser-Modus zurzeit nicht unterstützt. Diese Funktion kann im GitHub Issue verfolgt werden.
Wenn die factory definiert ist, geben alle Importe deren Ergebnis zurück. Vitest ruft die Factory nur einmal auf und speichert das Ergebnis für alle nachfolgenden Importe zwischen, bis vi.unmock oder vi.doUnmock aufgerufen wird.
Im Gegensatz zu jest kann die Factory asynchron sein, sodass vi.importActual oder eine Hilfsfunktion, die als erstes Argument empfangen wird, verwendet werden kann, um das ursprüngliche Modul abzurufen.
ts
```
vi.mock('./path/to/module.js', async importOriginal => {
  const mod = await importOriginal();
  return {
    ...mod,
    // replace some exports
    namedExport: vi.fn(),
  };
});
```
WARNING
vi.mock wird an den Anfang der Datei verschoben (mit anderen Worten, bewegt). Das bedeutet, dass es tatsächlich vorher aufgerufen wird, wann immer es geschrieben wird (sei es innerhalb von beforeEach oder test).
Dies bedeutet, dass keine Variablen innerhalb der Factory verwendet werden können, die außerhalb der Factory definiert sind.
Um Variablen innerhalb der Factory zu nutzen, kann vi.doMock verwendet werden. Es funktioniert auf die gleiche Weise, wird aber nicht nach oben verschoben (hoisted). Es ist zu beachten, dass es nur nachfolgende Importe mockt.
Es kann auch auf Variablen verwiesen werden, die von der vi.hoisted-Methode definiert wurden, wenn sie vor vi.mock deklariert wurde:
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
Beim Mocken eines Moduls mit einem Default-Export muss innerhalb des zurückgegebenen Factory-Funktionsobjekts ein default-Schlüssel angegeben werden. Dies ist ein ES-Modul-spezifischer Vorbehalt, daher kann sich die jest-Dokumentation unterscheiden, da jest CommonJS-Module verwendet. Zum Beispiel,
ts
```
vi.mock('./path/to/module.js', () => {
  return {
    default: { myDefaultKey: vi.fn() },
    namedExport: vi.fn(),
    // etc...
  };
});
```
Wenn ein __mocks__-Ordner neben einer Datei existiert, die gemockt wird, und die Factory nicht bereitgestellt wird, versucht Vitest, eine Datei mit demselben Namen im __mocks__-Unterordner zu finden und sie als tatsächliches Modul zu verwenden. Wenn eine Abhängigkeit mockiert wird, versucht Vitest, einen __mocks__-Ordner im Root des Projekts zu finden (Standard ist process.cwd()). Vitest kann mitgeteilt werden, wo sich die Abhängigkeiten befinden, über die Konfigurationsoption deps.moduleDirectories.
Zum Beispiel existiert diese Dateistruktur:
```
- __mocks__
  - axios.js
- src
  __mocks__
    - increment.js
  - increment.js
- tests
  - increment.test.js
```
Wenn vi.mock in einer Testdatei aufgerufen wird, ohne eine Factory bereitzustellen, wird eine Datei im __mocks__-Ordner gefunden, die als Modul verwendet werden soll:
ts
```
// increment.test.js
import { vi } from 'vitest';

// axios ist ein Standardexport von `__mocks__/axios.js`
import axios from 'axios';

// increment ist ein benannter Export von `src/__mocks__/increment.js`
import { increment } from '../increment.js';

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

axios.get(`/apples/${increment(1)}`);
```
WARNING
Es ist zu beachten, dass Module nicht automatisch gemockt werden, wenn vi.mock nicht aufgerufen wird. Um das automatische Mocking-Verhalten von Jest zu replizieren, kann vi.mock für jedes erforderliche Modul innerhalb von setupFiles aufgerufen werden.
Wenn kein __mocks__-Ordner oder keine Factory vorhanden ist, importiert Vitest das ursprüngliche Modul und mockt automatisch alle seine Exporte. Siehe [Algorithmus] für die angewendeten Regeln(../guide/mocking#automocking-algorithm).

vi.doMock

Typ: (path: string, factory?: () => unknown) => void
Funktioniert wie vi.mock, wird aber nicht an den Anfang der Datei verschoben (hoisted), wodurch auf Variablen im globalen Gültigkeitsbereich der Datei zugegriffen werden kann. Der nächste dynamische Import des Moduls wird gemockt. Dies mockt keine Module, die importiert wurden, bevor dies aufgerufen wurde.

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

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

// the module is not mocked, because vi.doMock is not called yet
increment(1) === 2;

let mockedIncrement = 100;

beforeEach(() => {
  // you can access variables inside a factory
  vi.doMock('./increment.js', () => ({ increment: () => ++mockedIncrement }));
});

test('importing the next module imports mocked one', async () => {
  // original import WAS NOT MOCKED, because vi.doMock is evaluated AFTER imports
  expect(increment(1)).toBe(2);
  const { increment: mockedIncrement } = await import('./increment.js');
  // new dynamic import returns mocked module
  expect(mockedIncrement(1)).toBe(101);
  expect(mockedIncrement(1)).toBe(102);
  expect(mockedIncrement(1)).toBe(103);
});

vi.mocked

Typ: <T>(obj: T, deep?: boolean) => MaybeMockedDeep<T>
Typ: <T>(obj: T, options?: { partial?: boolean; deep?: boolean }) => MaybePartiallyMockedDeep<T>
Typhilfe für TypeScript. Tatsächlich wird lediglich das übergebene Objekt zurückgegeben.
Wenn partial true ist, wird ein Partial<T> als Rückgabewert erwartet.
ts
```
import example from './example.js';

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

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

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

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

vi.importActual

Typ: <T>(path: string) => Promise<T>
Importiert ein Modul und umgeht alle Prüfungen, ob es gemockt werden soll. Kann nützlich sein, wenn ein Modul teilweise gemockt werden soll.
ts
```
vi.mock('./example.js', async () => {
  const axios = await vi.importActual('./example.js');

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

vi.importMock

Typ: <T>(path: string) => Promise<MaybeMockedDeep<T>>
Importiert ein Modul, wobei alle seine Eigenschaften (einschließlich verschachtelter Eigenschaften) gemockt werden. Befolgt die gleichen Regeln wie vi.mock. Siehe [Algorithmus] für die angewendeten Regeln(../guide/mocking#automocking-algorithm).

vi.resetAllMocks

Ruft für alle Spione .mockReset() auf. Dadurch wird die Mock-Historie gelöscht und die Implementierung auf eine leere Funktion zurückgesetzt (gibt undefined zurück).

vi.resetConfig

Typ: RuntimeConfig
Wenn vi.setConfig zuvor aufgerufen wurde, wird die Konfiguration auf den ursprünglichen Zustand zurückgesetzt.

vi.resetModules

Typ: () => Vitest

Setzt die Modulregistrierung zurück, indem der Cache aller Module gelöscht wird. Dadurch können Module neu bewertet werden, wenn sie erneut importiert werden. Top-Level-Importe können nicht neu bewertet werden. Kann hilfreich sein, um Module zu isolieren, deren lokale Zustände zwischen Tests in Konflikt geraten.

import { vi } from 'vitest';

import { data } from './data.js'; // Wird vor jedem Test nicht neu bewertet

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

test('change state', async () => {
  const mod = await import('./some/path.js'); // Wird neu bewertet
  mod.changeLocalState('new value');
  expect(mod.getLocalState()).toBe('new value');
});

test('module has old state', async () => {
  const mod = await import('./some/path.js'); // Wird neu bewertet
  expect(mod.getLocalState()).toBe('old value');
});

WARNING

Setzt die Mock-Registrierung nicht zurück. Um die Mock-Registrierung zu löschen, verwende vi.unmock oder vi.doUnmock.

vi.restoreAllMocks

Ruft für alle Spione .mockRestore() auf. Dadurch wird die Mock-Historie gelöscht und die Implementierung auf die ursprüngliche zurückgesetzt.

vi.stubEnv

Typ: (name: string, value: string) => Vitest
Version: Seit Vitest 0.26.0
Ändert den Wert der Umgebungsvariablen in process.env und import.meta.env. Der Wert kann wiederhergestellt werden, indem vi.unstubAllEnvs aufgerufen wird.

import { vi } from 'vitest';

// `process.env.NODE_ENV` und `import.meta.env.NODE_ENV`
// haben den Wert "development", bevor "vi.stubEnv" aufgerufen wird

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

process.env.NODE_ENV === 'production';
import.meta.env.NODE_ENV === 'production';
// ändert keine anderen Umgebungsvariablen
import.meta.env.MODE === 'development';

TIP

Der Wert kann auch einfach zugewiesen werden, aber vi.unstubAllEnvs kann nicht verwendet werden, um den vorherigen Wert wiederherzustellen:

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

vi.unstubAllEnvs

Typ: () => Vitest
Version: Seit Vitest 0.26.0
Setzt alle import.meta.env- und process.env-Werte zurück, die mit vi.stubEnv geändert wurden. Beim ersten Aufruf speichert Vitest die ursprünglichen Werte, die dann durch erneutes Aufrufen von vi.unstubAllEnvs wiederhergestellt werden können.

import { vi } from 'vitest';

// `process.env.NODE_ENV` und `import.meta.env.NODE_ENV`
// sind vor dem Aufruf von stubEnv auf "development" gesetzt

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();

// stellt die Werte wieder her, die vor dem ersten "stubEnv"-Aufruf gespeichert wurden
process.env.NODE_ENV === 'development';
import.meta.env.NODE_ENV === 'development';

vi.stubGlobal

Typ: (name: string | number | symbol, value: unknown) => Vitest
Ändert den Wert einer globalen Variablen. Der ursprüngliche Wert kann durch Aufruf von vi.unstubAllGlobals wiederhergestellt werden.

import { vi } from 'vitest';

// `innerWidth` ist vor dem Aufruf von stubGlobal "0"

vi.stubGlobal('innerWidth', 100);

innerWidth === 100;
globalThis.innerWidth === 100;
// wenn Sie jsdom oder happy-dom verwenden
window.innerWidth === 100;

TIP

Sie können den Wert auch ändern, indem Sie ihn einfach globalThis oder window zuweisen (wenn Sie die jsdom- oder happy-dom-Umgebung verwenden). Beachten Sie jedoch, dass Sie vi.unstubAllGlobals nicht verwenden können, um den ursprünglichen Wert wiederherzustellen:

globalThis.innerWidth = 100;
// wenn Sie jsdom oder happy-dom verwenden
window.innerWidth = 100;

vi.unstubAllGlobals

Typ: () => Vitest
Version: Seit Vitest 0.26.0
Setzt alle globalen Werte auf globalThis/global (und window/top/self/parent, wenn Sie die jsdom- oder happy-dom-Umgebung verwenden) zurück, die mit vi.stubGlobal geändert wurden. Beim ersten Aufruf speichert Vitest die ursprünglichen Werte, die dann durch erneutes Aufrufen von vi.unstubAllGlobals wiederhergestellt werden können.

import { vi } from 'vitest';

const Mock = vi.fn();

// IntersectionObserver ist vor dem Aufruf von "stubGlobal" "undefined"

vi.stubGlobal('IntersectionObserver', Mock);

IntersectionObserver === Mock;
global.IntersectionObserver === Mock;
globalThis.IntersectionObserver === Mock;
// wenn Sie jsdom oder happy-dom verwenden
window.IntersectionObserver === Mock;

vi.unstubAllGlobals();

globalThis.IntersectionObserver === undefined;
'IntersectionObserver' in globalThis === false;
// wirft ReferenceError, da es nicht definiert ist
IntersectionObserver === undefined;

vi.runAllTicks

Typ: () => Vitest
Führt alle Microtasks aus, die von process.nextTick in die Warteschlange gestellt wurden. Dadurch werden auch alle selbst geplanten Microtasks ausgeführt.

vi.runAllTimers

Typ: () => Vitest
Diese Methode führt alle initiierten Timer aus, bis die Timer-Warteschlange leer ist. Das bedeutet, dass jeder Timer, der während runAllTimers aufgerufen wird, ebenfalls ausgeführt wird. Bei einem unendlichen Intervall wird nach 10.000 Versuchen eine Ausnahme ausgelöst. Zum Beispiel protokolliert dies 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

Typ: () => Promise<Vitest>
Diese Methode führt alle initiierten Timer asynchron aus, bis die Timer-Warteschlange leer ist. Das bedeutet, dass jeder Timer, der während runAllTimersAsync aufgerufen wird, auch asynchrone Timer auslöst. Bei einem unendlichen Intervall wird nach 10.000 Versuchen eine Ausnahme ausgelöst. Zum Beispiel protokolliert dies result:
ts
```
setTimeout(async () => {
  console.log(await Promise.resolve('result'));
}, 100);

await vi.runAllTimersAsync();
```

vi.runOnlyPendingTimers

Typ: () => Vitest
Diese Methode führt alle Timer aus, die nach dem Aufruf von vi.useFakeTimers() initiiert wurden. Es wird kein Timer ausgelöst, der während des Aufrufs initiiert wurde. Zum Beispiel protokolliert dies nur 1:
ts
```
let i = 0;
setInterval(() => console.log(++i), 50);

vi.runOnlyPendingTimers();
```

vi.runOnlyPendingTimersAsync

Typ: () => Promise<Vitest>
Diese Methode führt alle Timer, die nach dem Aufruf von vi.useFakeTimers() initiiert wurden, asynchron aus, einschließlich asynchroner Timer. Es werden keine Timer ausgelöst, die während des Aufrufs erstellt wurden. Zum Beispiel protokolliert dies 2, 3, 3, 1:
ts
```
setTimeout(() => {
  console.log(1);
}, 100);
setTimeout(() => {
  Promise.resolve().then(() => {
    console.log(2);
    setInterval(() => {
      console.log(3);
    }, 40);
  });
}, 10);

await vi.runOnlyPendingTimersAsync();
```

vi.setSystemTime

Typ: (date: string | number | Date) => void
Setzt das aktuelle Datum auf das angegebene Datum. Alle Date-Aufrufe geben dieses Datum zurück.
Nützlich, wenn Sie etwas testen müssen, das vom aktuellen Datum abhängt - zum Beispiel luxon-Aufrufe in Ihrem Code.
ts
```
const date = new Date(1998, 11, 19);

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

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

vi.useRealTimers();
```

vi.setConfig

Typ: RuntimeConfig
Aktualisiert die Konfiguration für die aktuelle Testdatei. Sie können nur Werte beeinflussen, die bei der Ausführung von Tests verwendet werden.

vi.spyOn

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

Erstellt einen Spy auf eine Methode oder einen Getter/Setter eines Objekts.

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

Typ: (key: keyof globalThis & Window, value: any) => Vitest
Setzt einen Wert auf eine globale Variable. Wenn Sie jsdom oder happy-dom verwenden, wird der Wert auch auf das window-Objekt gesetzt.
Lesen Sie mehr im Abschnitt "Mocking Globals".

vi.unmock

Typ: (path: string) => void
Entfernt das Modul aus der Mock-Registry. Alle Aufrufe von import geben das ursprüngliche Modul zurück, auch wenn es zuvor gemockt wurde. Dieser Aufruf wird an den Anfang der Datei "gehoisted", wodurch nur Module entmockt werden, die beispielsweise in setupFiles definiert wurden.

vi.doUnmock

Typ: (path: string) => void
Funktioniert wie vi.unmock, wird aber nicht an den Anfang der Datei "gehoisted". Der nächste Import des Moduls importiert das ursprüngliche Modul anstelle des Mocks. Dies hebt das Mocking zuvor importierter Module nicht auf.

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

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

// increment ist bereits gemockt, da vi.mock hoisted ist
increment(1) === 100;

vi.mock('./increment.js', () => ({ increment: () => 100 }));

// alle Aufrufe werden gemockt, und `increment` gibt immer 100 zurück
increment(1) === 100;
increment(30) === 100;

vi.doUnmock('./increment.js');

// dies gibt IMMER NOCH 100 zurück, da `vi.doUnmock` ein Modul nicht neu bewertet
increment(1) === 100;
increment(30) === 100;

// der nächste Import ist ungemockt, jetzt ist `increment` die ursprüngliche Funktion, die count + 1 zurückgibt
const { increment: unmockedIncrement } = await import('./increment.js');

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

vi.useFakeTimers

Typ: () => Vitest
Um das Mocken von Timern zu aktivieren, müssen Sie diese Methode aufrufen. Es werden alle nachfolgenden Aufrufe von Timern (wie setTimeout, setInterval, clearTimeout, clearInterval, nextTick, setImmediate, clearImmediate und Date) abgefangen und durch Mock-Implementierungen ersetzt, bis vi.useRealTimers() aufgerufen wird.
Das Mocken von nextTick wird nicht unterstützt, wenn Vitest innerhalb von node:child_process mit --no-threads ausgeführt wird. NodeJS verwendet process.nextTick intern in node:child_process und hängt sich auf, wenn es gemockt wird. Das Mocken von nextTick wird unterstützt, wenn Vitest mit --threads ausgeführt wird.
Die Implementierung basiert intern auf @sinonjs/fake-timers.
TIP
Seit Version 0.35.0 mockt vi.useFakeTimers() nicht mehr automatisch process.nextTick. Es kann weiterhin gemockt werden, indem die Option im toFake-Argument angegeben wird: vi.useFakeTimers({ toFake: ['nextTick'] }).

vi.isFakeTimers

Typ: () => boolean
Version: Seit Vitest 0.34.5
Gibt true zurück, wenn Fake-Timer aktiviert sind.

vi.useRealTimers

Typ: () => Vitest
Nachdem die Fake-Timer verwendet wurden, kann diese Methode aufgerufen werden, um die Mock-Implementierungen durch die ursprünglichen Timer-Funktionen zu ersetzen. Alle Timer, die zuvor ausgeführt wurden, werden nicht wiederhergestellt.

vi.waitFor

Typ: <T>(callback: WaitForCallback<T>, options?: number | WaitForOptions) => Promise<T>
Version: Seit Vitest 0.34.5

Wartet darauf, dass die Funktion erfolgreich ausgeführt wird. Wenn die Funktion einen Fehler auslöst oder ein verworfenes Promise (rejected Promise) zurückgibt, wird so lange gewartet, bis sie erfolgreich ist oder ein Timeout eintritt.

Dies ist sehr nützlich, wenn Sie warten müssen, bis eine asynchrone Aktion abgeschlossen ist, z. B. wenn Sie einen Server starten und warten müssen, bis er gestartet ist.

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, // default is 1000
      interval: 20, // default is 50
    }
  );
  expect(server.isReady).toBe(true);
});

Es funktioniert auch für asynchrone Funktionen

// @vitest-environment jsdom

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

test('Element exists in a DOM', async () => {
  // start populating DOM
  populateDOMAsync();

  const element = await vi.waitFor(
    async () => {
      // try to get the element until it exists
      const element = (await getDOMElementAsync()) as HTMLElement | null;
      expect(element).toBeTruthy();
      expect(element.dataset.initialized).toBeTruthy();
      return element;
    },
    {
      timeout: 500, // default is 1000
      interval: 20, // default is 50
    }
  );
  expect(element).toBeInstanceOf(HTMLElement);
});

Wenn vi.useFakeTimers verwendet wird, ruft vi.waitFor automatisch vi.advanceTimersByTime(interval) in jeder Check-Funktion auf.

vi.waitUntil

Typ: <T>(callback: WaitUntilCallback<T>, options?: number | WaitUntilOptions) => Promise<T>
Version: Seit Vitest 0.34.5

Dies ähnelt vi.waitFor, jedoch wird die Ausführung sofort unterbrochen und eine Fehlermeldung angezeigt, wenn die Funktion einen Fehler auslöst. Wenn die Funktion einen "falsy" Wert zurückgibt, wird die nächste Überprüfung so lange fortgesetzt, bis ein "truthy" Wert zurückgegeben wird. Dies ist nützlich, wenn Sie warten müssen, bis etwas vorhanden ist, bevor Sie den nächsten Schritt ausführen.

Sehen Sie sich das folgende Beispiel an. Wir können vi.waitUntil verwenden, um zu warten, bis das Element auf der Seite angezeigt wird, und dann können wir etwas mit dem Element tun.

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

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

  // do something with the element
  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