Experimenteller Browser-Modus

Diese Seite beschreibt die experimentelle Browser-Modus-Funktion der Vitest-API. Sie ermöglicht die native Ausführung von Tests im Browser und bietet Zugriff auf globale Browser-Objekte wie window und document. Diese Funktion befindet sich derzeit in der Entwicklung, und APIs können sich in Zukunft ändern.

Motivation

Die Vitest Browser-Modus-Funktion wurde entwickelt, um Testworkflows zu optimieren und präzisere, zuverlässigere Testergebnisse zu liefern. Diese experimentelle Erweiterung der Test-API erlaubt es Entwicklern, Tests direkt in einer nativen Browserumgebung auszuführen. Dieser Abschnitt erläutert die Motivation hinter dieser Funktion und ihre Vorteile für das Testen.

Unterschiedliche Testmethoden

Es gibt verschiedene Ansätze zum Testen von JavaScript-Code. Einige Testframeworks simulieren Browserumgebungen in Node.js, während andere Tests in echten Browsern ausführen. Ein Beispiel für eine Spezifikationsimplementierung, die eine Browserumgebung simuliert, ist jsdom, das oft mit Testrunnern wie Jest oder Vitest verwendet wird. Im Gegensatz dazu ermöglichen Testwerkzeuge wie WebdriverIO oder Cypress das Testen von Anwendungen in einem echten Browser. Playwright stellt sogar eine eigene Browser-Engine bereit.

Einschränkungen der Simulation

Das Testen von JavaScript-Programmen in simulierten Umgebungen wie jsdom oder happy-dom vereinfacht die Testumgebung und bietet eine benutzerfreundliche API. Dadurch eignen sie sich für viele Projekte und stärken das Vertrauen in die Testergebnisse. Es ist jedoch wichtig zu bedenken, dass diese Tools lediglich eine Browserumgebung simulieren und keinen echten Browser darstellen, was zu Diskrepanzen zwischen der simulierten Umgebung und der realen Umgebung führen kann. Daher können falsch-positive oder falsch-negative Testergebnisse auftreten.

Um das höchste Maß an Vertrauen in unsere Tests zu erreichen, ist es entscheidend, in einer realen Browserumgebung zu testen. Aus diesem Grund haben wir die Browser-Modus-Funktion in Vitest entwickelt, die es Entwicklern ermöglicht, Tests nativ in einem Browser auszuführen und zuverlässigere und genauere Testergebnisse zu erzielen. Durch Browser-basierte Tests können Entwickler sicherer sein, dass ihre Anwendung in einem realen Szenario wie vorgesehen funktioniert.

Nachteile

Bei der Verwendung von Vitest Browser ist es wichtig, die folgenden Nachteile zu berücksichtigen:

Frühes Entwicklungsstadium

Die Browser-Modus-Funktion von Vitest befindet sich noch in einem frühen Entwicklungsstadium. Daher ist sie möglicherweise noch nicht vollständig optimiert, und es kann einige Fehler oder Probleme geben, die noch nicht behoben wurden. Es wird empfohlen, dass Benutzer ihre Erfahrungen mit dem Vitest-Browser durch die Verwendung eines separaten Testrunners für den Browser wie WebdriverIO, Cypress oder Playwright ergänzen.

Längere Initialisierung

Vitest Browser erfordert das Starten des Providers und des Browsers während des Initialisierungsprozesses, was einige Zeit in Anspruch nehmen kann. Dies kann zu längeren Initialisierungszeiten im Vergleich zu anderen Testansätzen führen.

Konfiguration

Um den Browser-Modus in Ihrer Vitest-Konfiguration zu aktivieren, können Sie das Flag --browser verwenden oder das Feld browser.enabled in Ihrer Vitest-Konfigurationsdatei auf true setzen. Hier ist ein Beispiel für eine Konfiguration mit dem Browser-Feld:

export default defineConfig({
  test: {
    browser: {
      enabled: true,
      name: 'chrome', // Browsername ist erforderlich
    },
  },
});

Browser-Optionen:

Die Browser-Option in Vitest hängt vom Provider ab. Vitest gibt eine Fehlermeldung aus, wenn Sie --browser übergeben und den Namen des Browsers nicht in der Konfigurationsdatei angeben. Verfügbare Optionen:

• webdriverio (Standard) unterstützt diese Browser:
  • firefox
  • chrome
  • edge
  • safari
• playwright unterstützt diese Browser:
  • firefox
  • webkit
  • chromium

Browserübergreifende Tests:

Wenn Sie einen Browsernamen in der Browser-Option angeben, versucht Vitest standardmäßig, den angegebenen Browser mit WebdriverIO auszuführen und dann die Tests dort auszuführen. Diese Funktion vereinfacht browserübergreifende Tests und deren Konfiguration in Umgebungen wie einer CI. Wenn Sie WebdriverIO nicht verwenden möchten, können Sie den benutzerdefinierten Browser-Provider mit der Option browser.provider konfigurieren.

Um einen Browser über die CLI anzugeben, verwenden Sie das Flag --browser, gefolgt vom Browsernamen, wie folgt:

npx vitest --browser=chrome

Oder Sie können Browseroptionen mit Punktnotation an die CLI übergeben:

npx vitest --browser.name=chrome --browser.headless

NOTE

Wenn Sie die Safari-Browseroption mit WebdriverIO verwenden, muss der safaridriver durch Ausführen von sudo safaridriver --enable auf Ihrem Gerät aktiviert werden.

Wenn Sie Ihre Tests ausführen, versucht Vitest außerdem, einige Treiber für die Kompatibilität mit safaridriver zu installieren.

Headless-Modus

Der Headless-Modus ist eine weitere Option, die im Browser-Modus verfügbar ist. Im Headless-Modus läuft der Browser im Hintergrund ohne Benutzeroberfläche, was ihn für die Ausführung automatisierter Tests nützlich macht. Die Headless-Option in Vitest kann auf einen booleschen Wert gesetzt werden, um den Headless-Modus zu aktivieren oder zu deaktivieren.

Hier ist eine Beispielkonfiguration, die den Headless-Modus aktiviert:

export default defineConfig({
  test: {
    browser: {
      enabled: true,
      headless: true,
    },
  },
});

Sie können den Headless-Modus auch mit dem Flag --browser.headless in der CLI festlegen, wie folgt:

npx vitest --browser.name=chrome --browser.headless

In diesem Fall wird Vitest im Headless-Modus mit dem Chrome-Browser ausgeführt.

Einschränkungen

Dialoge, die den Thread blockieren

Bei der Verwendung von Vitest Browser ist es wichtig zu beachten, dass Dialoge, die den Thread blockieren, wie alert oder confirm, nicht nativ verwendet werden können. Dies liegt daran, dass sie die Webseite blockieren, was bedeutet, dass Vitest nicht mehr mit der Seite kommunizieren kann, was dazu führt, dass die Ausführung hängen bleibt.

In solchen Situationen stellt Vitest Standard-Mockups mit Standard-Rückgabewerten für diese APIs bereit. Dies stellt sicher, dass die Ausführung nicht hängen bleibt, wenn der Benutzer versehentlich synchronisierende Web-API-Popups verwendet. Es wird jedoch weiterhin empfohlen, dass der Benutzer diese Web-APIs für eine bessere Benutzererfahrung mockt. Lesen Sie mehr unter Mocking.