Runner

Runner w WebdriverIO orkiestruje jak i gdzie testy są uruchamiane podczas korzystania z testrunner. WebdriverIO obecnie obsługuje dwa różne typy runnerów: lokalny i przeglądarkowy.

Local Runner

Local Runner inicjuje twój framework (np. Mocha, Jasmine lub Cucumber) w procesie roboczym i uruchamia wszystkie pliki testowe w środowisku Node.js. Każdy plik testowy jest uruchamiany w osobnym procesie roboczym dla każdej funkcjonalności, co pozwala na maksymalną współbieżność. Każdy proces roboczy wykorzystuje pojedynczą instancję przeglądarki i dlatego uruchamia własną sesję przeglądarki, zapewniając maksymalną izolację.

Ponieważ każdy test jest uruchamiany we własnym izolowanym procesie, nie jest możliwe udostępnianie danych między plikami testowymi. Istnieją dwa sposoby obejścia tego:

• użyj @wdio/shared-store-service do udostępniania danych między wszystkimi pracownikami
• grupuj pliki specyfikacji (przeczytaj więcej w Organizacja zestawu testów)

Jeśli nic innego nie jest zdefiniowane w wdio.conf.js, Local Runner jest domyślnym runnerem w WebdriverIO.

Instalacja

Aby korzystać z Local Runner, możesz go zainstalować za pomocą:

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

Konfiguracja

Local Runner jest domyślnym runnerem w WebdriverIO, więc nie ma potrzeby definiowania go w wdio.conf.js. Jeśli chcesz go jawnie ustawić, możesz zdefiniować go w następujący sposób:

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

Browser Runner

W przeciwieństwie do Local Runner, Browser Runner inicjuje i wykonuje framework wewnątrz przeglądarki. Pozwala to na uruchamianie testów jednostkowych lub testów komponentów w rzeczywistej przeglądarce, a nie w JSDOM, jak wiele innych frameworków testowych.

Podczas gdy JSDOM jest szeroko stosowany do celów testowania, to ostatecznie nie jest prawdziwą przeglądarką, ani nie można za jego pomocą emulować środowisk mobilnych. Dzięki temu runnerowi WebdriverIO umożliwia łatwe uruchamianie testów w przeglądarce i korzystanie z poleceń WebDriver do interakcji z elementami renderowanymi na stronie.

Oto przegląd uruchamiania testów w JSDOM vs. WebdriverIOs Browser Runner

	JSDOM	WebdriverIO Browser Runner
1.	Uruchamia testy w Node.js korzystając z reimplementacji standardów sieciowych, zwłaszcza standardów WHATWG DOM i HTML	Wykonuje testy w rzeczywistej przeglądarce i uruchamia kod w środowisku, z którego korzystają Twoi użytkownicy
2.	Interakcje z komponentami mogą być tylko imitowane za pomocą JavaScript	Możesz używać WebdriverIO API do interakcji z elementami przez protokół WebDriver
3.	Obsługa Canvas wymaga dodatkowych zależności i ma ograniczenia	Masz dostęp do prawdziwego Canvas API
4.	JSDOM ma pewne zastrzeżenia i nieobsługiwane API internetowe	Wszystkie API internetowe są obsługiwane, ponieważ testy działają w rzeczywistej przeglądarce
5.	Niemożliwe jest wykrycie błędów między przeglądarkami	Obsługa wszystkich przeglądarek, w tym przeglądarek mobilnych
6.	Nie może testować stanów pseudoelementów	Obsługa stanów pseudo, takich jak :hover lub :active

Ten runner używa Vite do kompilacji kodu testowego i ładowania go w przeglądarce. Zawiera gotowe ustawienia dla następujących frameworków komponentów:

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

Każdy plik testowy / grupa plików testowych działa w ramach pojedynczej strony, co oznacza, że między każdym testem strona jest przeładowywana, aby zagwarantować izolację między testami.

Instalacja

Aby korzystać z Browser Runnera, możesz go zainstalować za pomocą:

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

Konfiguracja

Aby używać Browser runnera, musisz zdefiniować właściwość runner w pliku wdio.conf.js, np.:

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

Opcje Runnera

Browser runner pozwala na następujące konfiguracje:

preset

Jeśli testujesz komponenty przy użyciu jednego z wymienionych powyżej frameworków, możesz zdefiniować preset, który zapewnia, że wszystko jest skonfigurowane od razu. Ta opcja nie może być używana razem z viteConfig.

Typ: vue | svelte | solid | react | preact | stencil
Przykład:

wdio.conf.js

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

viteConfig

Zdefiniuj własną konfigurację Vite. Możesz przekazać niestandardowy obiekt lub zaimportować istniejący plik vite.conf.ts, jeśli używasz Vite.js do rozwoju. Pamiętaj, że WebdriverIO zachowuje niestandardowe konfiguracje Vite do konfiguracji harnessu testowego.

Typ: string lub UserConfig lub (env: ConfigEnv) => UserConfig | Promise<UserConfig>
Przykład:

wdio.conf.ts

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

export const {
    // ...
    runner: ['browser', { viteConfig }],
    // lub po prostu:
    runner: ['browser', { viteConfig: '../vites.config.ts' }],
    // lub użyj funkcji jeśli twoja konfiguracja vite zawiera dużo wtyczek
    // które chcesz rozwiązać tylko wtedy, gdy wartość jest odczytywana
    runner: ['browser', {
        viteConfig: () => ({
            // ...
        })
    }],
    // ...
}

headless

Jeśli ustawione na true, runner zaktualizuje możliwości, aby uruchomić testy w trybie headless. Domyślnie jest to włączone w środowiskach CI, gdzie zmienna środowiskowa CI jest ustawiona na '1' lub 'true'.

Typ: boolean
Domyślnie: false, ustawione na true jeśli zmienna środowiskowa CI jest ustawiona

rootDir

Katalog główny projektu.

Typ: string
Domyślnie: process.cwd()

coverage

WebdriverIO obsługuje raportowanie pokrycia testowego przez istanbul. Zobacz Opcje pokrycia aby uzyskać więcej szczegółów.

Typ: object
Domyślnie: undefined

Opcje pokrycia

Następujące opcje pozwalają skonfigurować raportowanie pokrycia.

enabled

Włącza zbieranie pokrycia.

Typ: boolean
Domyślnie: false

include

Lista plików włączonych do pokrycia jako wzorce glob.

Typ: string[]
Domyślnie: [**]

exclude

Lista plików wykluczonych z pokrycia jako wzorce glob.

Typ: string[]
Domyślnie:

[
  '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

Lista rozszerzeń plików, które raport powinien zawierać.

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

reportsDirectory

Katalog, do którego zostanie zapisany raport pokrycia.

Typ: string
Domyślnie: ./coverage

reporter

Reportery pokrycia do użycia. Zobacz dokumentację istanbul dla szczegółowej listy wszystkich reporterów.

Typ: string[]
Domyślnie: ['text', 'html', 'clover', 'json-summary']

perFile

Sprawdź progi dla każdego pliku. Zobacz lines, functions, branches i statements dla faktycznych progów.

Typ: boolean
Domyślnie: false

clean

Wyczyść wyniki pokrycia przed uruchomieniem testów.

Typ: boolean
Domyślnie: true

lines

Próg dla linii.

Typ: number
Domyślnie: undefined

functions

Próg dla funkcji.

Typ: number
Domyślnie: undefined

branches

Próg dla gałęzi.

Typ: number
Domyślnie: undefined

statements

Próg dla instrukcji.

Typ: number
Domyślnie: undefined

Ograniczenia

Korzystając z WebdriverIO browser runner, ważne jest, aby pamiętać, że blokujące dialogi, takie jak alert lub confirm, nie mogą być używane natywnie. Dzieje się tak, ponieważ blokują one stronę internetową, co oznacza, że WebdriverIO nie może kontynuować komunikacji ze stroną, powodując zawieszenie wykonania.

W takich sytuacjach WebdriverIO dostarcza domyślne zaślepki z domyślnymi zwracanymi wartościami dla tych API. Zapewnia to, że jeśli użytkownik przypadkowo użyje synchronicznych wyskakujących internetowych API, wykonanie nie zawiesi się. Zaleca się jednak, aby użytkownik zaślepiał te internetowe API dla lepszego doświadczenia. Przeczytaj więcej w Mockowanie.

Przykłady

Koniecznie sprawdź dokumentację dotyczącą testowania komponentów i zajrzyj do repozytorium przykładów w poszukiwaniu przykładów korzystających z tych i różnych innych frameworków.