Runner

Ein Runner in WebdriverIO orchestriert, wie und wo Tests ausgeführt werden, wenn der Testrunner verwendet wird. WebdriverIO unterstützt derzeit zwei verschiedene Arten von Runnern: lokaler Runner und Browser-Runner.

Local Runner

Der Local Runner initiiert Ihr Framework (z.B. Mocha, Jasmine oder Cucumber) innerhalb eines Worker-Prozesses und führt alle Ihre Testdateien in Ihrer Node.js-Umgebung aus. Jede Testdatei wird in einem separaten Worker-Prozess pro Capability ausgeführt, was maximale Parallelität ermöglicht. Jeder Worker-Prozess verwendet eine einzelne Browser-Instanz und führt daher seine eigene Browser-Sitzung aus, was maximale Isolation ermöglicht.

Da jeder Test in seinem eigenen isolierten Prozess ausgeführt wird, ist es nicht möglich, Daten über Testdateien hinweg zu teilen. Es gibt zwei Möglichkeiten, dies zu umgehen:

• Verwenden Sie den @wdio/shared-store-service, um Daten über alle Worker hinweg zu teilen
• Gruppieren Sie Spec-Dateien (lesen Sie mehr unter Organizing Test Suite)

Wenn in der wdio.conf.js nichts anderes definiert ist, ist der Local Runner der Standard-Runner in WebdriverIO.

Installation

Um den Local Runner zu verwenden, können Sie ihn wie folgt installieren:

npm install --save-dev @wdio/local-runner

Einrichtung

Der Local Runner ist der Standard-Runner in WebdriverIO, daher müssen Sie ihn nicht in Ihrer wdio.conf.js definieren. Wenn Sie ihn explizit festlegen möchten, können Sie ihn wie folgt definieren:

// wdio.conf.js
export const {
    // ...
    runner: 'local',
    // ...
}

Browser Runner

Im Gegensatz zum Local Runner initiiert und führt der Browser Runner das Framework innerhalb des Browsers aus. Dies ermöglicht es Ihnen, Unit-Tests oder Komponententests in einem echten Browser auszuführen, anstatt in einer JSDOM wie bei vielen anderen Test-Frameworks.

Während JSDOM für Testzwecke weit verbreitet ist, ist es letztendlich kein echter Browser, noch können Sie damit mobile Umgebungen emulieren. Mit diesem Runner ermöglicht WebdriverIO Ihnen, Ihre Tests einfach im Browser auszuführen und WebDriver-Befehle zu verwenden, um mit auf der Seite gerenderten Elementen zu interagieren.

Hier ist ein Überblick über die Ausführung von Tests in JSDOM im Vergleich zum WebdriverIO Browser Runner

	JSDOM	WebdriverIO Browser Runner
1.	Führt Ihre Tests in Node.js aus und verwendet eine Reimplementierung von Webstandards, insbesondere der WHATWG DOM und HTML Standards	Führt Ihren Test in einem echten Browser aus und führt den Code in einer Umgebung aus, die Ihre Benutzer verwenden
2.	Interaktionen mit Komponenten können nur über JavaScript imitiert werden	Sie können die WebdriverIO API verwenden, um mit Elementen über das WebDriver-Protokoll zu interagieren
3.	Canvas-Unterstützung erfordert zusätzliche Abhängigkeiten und hat Einschränkungen	Sie haben Zugriff auf die echte Canvas API
4.	JSDOM hat einige Einschränkungen und nicht unterstützte Web-APIs	Alle Web-APIs werden unterstützt, da Tests in einem echten Browser laufen
5.	Unmöglich, Fehler browserübergreifend zu erkennen	Unterstützung für alle Browser einschließlich mobiler Browser
6.	Kann Elementpseudozustände nicht testen	Unterstützung für Pseudozustände wie :hover oder :active

Dieser Runner verwendet Vite, um Ihren Testcode zu kompilieren und in den Browser zu laden. Er enthält Voreinstellungen für die folgenden Komponenten-Frameworks:

• React
• Preact
• Vue.js
• Svelte
• SolidJS
• Stencil

Jede Testdatei / Testdateigruppe läuft innerhalb einer einzelnen Seite, was bedeutet, dass zwischen jedem Test die Seite neu geladen wird, um die Isolation zwischen Tests zu gewährleisten.

Installation

Um den Browser Runner zu verwenden, können Sie ihn wie folgt installieren:

npm install --save-dev @wdio/browser-runner

Einrichtung

Um den Browser Runner zu verwenden, müssen Sie eine runner-Eigenschaft in Ihrer wdio.conf.js-Datei definieren, z.B.:

// wdio.conf.js
export const {
    // ...
    runner: 'browser',
    // ...
}

Runner-Optionen

Der Browser Runner ermöglicht folgende Konfigurationen:

preset

Wenn Sie Komponenten mit einem der oben genannten Frameworks testen, können Sie ein Preset definieren, das sicherstellt, dass alles von Anfang an konfiguriert ist. Diese Option kann nicht zusammen mit viteConfig verwendet werden.

Typ: vue | svelte | solid | react | preact | stencil
Beispiel:

wdio.conf.js

export const {
    // ...
    runner: ['browser', {
        preset: 'svelte'
    }],
    // ...
}

viteConfig

Definieren Sie Ihre eigene Vite-Konfiguration. Sie können entweder ein benutzerdefiniertes Objekt übergeben oder eine bestehende vite.conf.ts-Datei importieren, wenn Sie Vite.js für die Entwicklung verwenden. Beachten Sie, dass WebdriverIO benutzerdefinierte Vite-Konfigurationen beibehält, um die Testumgebung einzurichten.

Typ: string oder UserConfig oder (env: ConfigEnv) => UserConfig | Promise<UserConfig>
Beispiel:

wdio.conf.ts

import viteConfig from '../vite.config.ts'

export const {
    // ...
    runner: ['browser', { viteConfig }],
    // oder einfach:
    runner: ['browser', { viteConfig: '../vites.config.ts' }],
    // oder verwenden Sie eine Funktion, wenn Ihre Vite-Konfiguration viele Plugins enthält,
    // die Sie nur auflösen möchten, wenn der Wert gelesen wird
    runner: ['browser', {
        viteConfig: () => ({
            // ...
        })
    }],
    // ...
}

headless

Wenn auf true gesetzt, aktualisiert der Runner die Capabilities, um Tests im Headless-Modus auszuführen. Standardmäßig ist dies in CI-Umgebungen aktiviert, in denen eine CI-Umgebungsvariable auf '1' oder 'true' gesetzt ist.

Typ: boolean
Standard: false, auf true gesetzt, wenn die CI-Umgebungsvariable gesetzt ist

rootDir

Projektstammverzeichnis.

Typ: string
Standard: process.cwd()

coverage

WebdriverIO unterstützt die Berichterstattung über Testabdeckung durch istanbul. Weitere Details finden Sie unter Coverage-Optionen.

Typ: object
Standard: undefined

Coverage-Optionen

Die folgenden Optionen ermöglichen die Konfiguration der Coverage-Berichterstattung.

enabled

Aktiviert die Coverage-Erfassung.

Typ: boolean
Standard: false

include

Liste der in die Coverage eingeschlossenen Dateien als Glob-Muster.

Typ: string[]
Standard: [**]

exclude

Liste der von der Coverage ausgeschlossenen Dateien als Glob-Muster.

Typ: string[]
Standard:

[
  'coverage/**',
  'dist/**',
  'packages/*/test{,s}/**',
  '**/*.d.ts',
  'cypress/**',
  'test{,s}/**',
  'test{,-*}.{js,cjs,mjs,ts,tsx,jsx}',
  '**/*{.,-}test.{js,cjs,mjs,ts,tsx,jsx}',
  '**/*{.,-}spec.{js,cjs,mjs,ts,tsx,jsx}',
  '**/__tests__/**',
  '**/{karma,rollup,webpack,vite,vitest,jest,ava,babel,nyc,cypress,tsup,build}.config.*',
  '**/.{eslint,mocha,prettier}rc.{js,cjs,yml}',
]

extension

Liste der Dateierweiterungen, die der Bericht enthalten sollte.

Typ: string | string[]
Standard: ['.js', '.cjs', '.mjs', '.ts', '.mts', '.cts', '.tsx', '.jsx', '.vue', '.svelte']

reportsDirectory

Verzeichnis, in das der Coverage-Bericht geschrieben werden soll.

Typ: string
Standard: ./coverage

reporter

Zu verwendende Coverage-Reporter. Siehe istanbul-Dokumentation für eine detaillierte Liste aller Reporter.

Typ: string[]
Standard: ['text', 'html', 'clover', 'json-summary']

perFile

Überprüft Schwellenwerte pro Datei. Siehe lines, functions, branches und statements für die tatsächlichen Schwellenwerte.

Typ: boolean
Standard: false

clean

Bereinigt Coverage-Ergebnisse vor dem Ausführen von Tests.

Typ: boolean
Standard: true

lines

Schwellenwert für Zeilen.

Typ: number
Standard: undefined

functions

Schwellenwert für Funktionen.

Typ: number
Standard: undefined

branches

Schwellenwert für Branches.

Typ: number
Standard: undefined

statements

Schwellenwert für Anweisungen.

Typ: number
Standard: undefined

Einschränkungen

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

In solchen Situationen stellt WebdriverIO Standard-Mocks mit Standardrückgabewerten für diese APIs bereit. Dies stellt sicher, dass, wenn der Benutzer versehentlich synchrone Popup-Web-APIs verwendet, die Ausführung nicht hängen bleibt. Es wird jedoch empfohlen, dass der Benutzer diese Web-APIs für eine bessere Erfahrung mockt. Lesen Sie mehr unter Mocking.

Beispiele

Schauen Sie sich unbedingt die Dokumentation zum Komponententesting an und werfen Sie einen Blick in das Beispiel-Repository für Beispiele, die diese und verschiedene andere Frameworks verwenden.