Vai al contenuto principale

Runner

Un runner in WebdriverIO orchestra come e dove vengono eseguiti i test quando si utilizza il testrunner. WebdriverIO supporta attualmente due diversi tipi di runner: locale e browser runner.

Local Runner

Il Local Runner avvia il tuo framework (ad esempio Mocha, Jasmine o Cucumber) all'interno di un processo worker ed esegue tutti i tuoi file di test all'interno del tuo ambiente Node.js. Ogni file di test viene eseguito in un processo worker separato per ogni capability, consentendo la massima concorrenza. Ogni processo worker utilizza una singola istanza del browser e quindi esegue la propria sessione del browser, consentendo la massima isolazione.

Dato che ogni test viene eseguito nel suo processo isolato, non è possibile condividere dati tra i file di test. Ci sono due modi per aggirare questo problema:

Se non è definito nient'altro nel wdio.conf.js, il Local Runner è il runner predefinito in WebdriverIO.

Install

Per utilizzare il Local Runner puoi installarlo tramite:

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

Setup

Il Local Runner è il runner predefinito in WebdriverIO, quindi non è necessario definirlo all'interno del tuo wdio.conf.js. Se vuoi impostarlo esplicitamente, puoi definirlo come segue:

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

Browser Runner

A differenza del Local Runner, il Browser Runner avvia ed esegue il framework all'interno del browser. Questo ti permette di eseguire unit test o component test in un browser reale piuttosto che in un JSDOM come molti altri framework di test.

Mentre JSDOM è ampiamente utilizzato per scopi di test, alla fine non è un browser reale né puoi emulare ambienti mobili con esso. Con questo runner, WebdriverIO ti consente di eseguire facilmente i tuoi test nel browser e utilizzare i comandi WebDriver per interagire con gli elementi renderizzati sulla pagina.

Ecco una panoramica dell'esecuzione di test all'interno di JSDOM rispetto al Browser Runner di WebdriverIO

JSDOMWebdriverIO Browser Runner
1.Esegue i tuoi test all'interno di Node.js utilizzando una reimplementazione degli standard web, in particolare gli standard WHATWG DOM e HTMLEsegue il tuo test in un browser reale ed esegue il codice in un ambiente che i tuoi utenti utilizzano
2.Le interazioni con i componenti possono essere imitate solo tramite JavaScriptPuoi utilizzare l'API WebdriverIO per interagire con gli elementi attraverso il protocollo WebDriver
3.Il supporto Canvas richiede dipendenze aggiuntive e ha limitazioniHai accesso alla vera API Canvas
4.JSDOM ha alcune avvertenze e API Web non supportateTutte le API Web sono supportate poiché i test vengono eseguiti in un browser reale
5.Impossibile rilevare errori cross browserSupporto per tutti i browser, inclusi i browser mobili
6.Non può testare gli stati pseudo degli elementiSupporto per stati pseudo come :hover o :active

Questo runner utilizza Vite per compilare il tuo codice di test e caricarlo nel browser. Viene fornito con preset per i seguenti framework di componenti:

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

Ogni file di test / gruppo di file di test viene eseguito all'interno di una singola pagina, il che significa che tra un test e l'altro la pagina viene ricaricata per garantire l'isolamento tra i test.

Install

Per utilizzare il Browser Runner puoi installarlo tramite:

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

Setup

Per utilizzare il Browser runner, devi definire una proprietà runner all'interno del tuo file wdio.conf.js, ad esempio:

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

Runner Options

Il Browser runner consente le seguenti configurazioni:

preset

Se testi componenti utilizzando uno dei framework menzionati sopra, puoi definire un preset che assicura che tutto sia configurato già pronto all'uso. Questa opzione non può essere utilizzata insieme a viteConfig.

Type: vue | svelte | solid | react | preact | stencil
Example:

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

viteConfig

Definisci la tua configurazione Vite. Puoi passare un oggetto personalizzato o importare un file vite.conf.ts esistente se utilizzi Vite.js per lo sviluppo. Nota che WebdriverIO mantiene configurazioni Vite personalizzate per impostare l'harness di test.

Type: string o UserConfig o (env: ConfigEnv) => UserConfig | Promise<UserConfig>
Example:

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

export const {
// ...
runner: ['browser', { viteConfig }],
// or just:
runner: ['browser', { viteConfig: '../vites.config.ts' }],
// or use a function if your vite config contains a lot of plugins
// which you only want to resolve when value is read
runner: ['browser', {
viteConfig: () => ({
// ...
})
}],
// ...
}

headless

Se impostato su true, il runner aggiornerà le capabilities per eseguire i test in modalità headless. Per impostazione predefinita, questo è abilitato negli ambienti CI dove una variabile d'ambiente CI è impostata su '1' o 'true'.

Type: boolean
Default: false, impostato su true se la variabile d'ambiente CI è impostata

rootDir

Directory root del progetto.

Type: string
Default: process.cwd()

coverage

WebdriverIO supporta la generazione di report di copertura dei test tramite istanbul. Vedi Coverage Options per maggiori dettagli.

Type: object
Default: undefined

Coverage Options

Le seguenti opzioni consentono di configurare il reporting della copertura.

enabled

Abilita la raccolta della copertura.

Type: boolean
Default: false

include

Elenco di file inclusi nella copertura come pattern glob.

Type: string[]
Default: [**]

exclude

Elenco di file esclusi dalla copertura come pattern glob.

Type: string[]
Default:

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

Elenco delle estensioni di file che il report dovrebbe includere.

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

reportsDirectory

Directory in cui scrivere il report di copertura.

Type: string
Default: ./coverage

reporter

Reporter di copertura da utilizzare. Vedi la documentazione di istanbul per un elenco dettagliato di tutti i reporter.

Type: string[]
Default: ['text', 'html', 'clover', 'json-summary']

perFile

Verifica le soglie per file. Vedi lines, functions, branches e statements per le soglie effettive.

Type: boolean
Default: false

clean

Pulisci i risultati di copertura prima di eseguire i test.

Type: boolean
Default: true

lines

Soglia per le linee.

Type: number
Default: undefined

functions

Soglia per le funzioni.

Type: number
Default: undefined

branches

Soglia per i rami.

Type: number
Default: undefined

statements

Soglia per le istruzioni.

Type: number
Default: undefined

Limitations

Quando si utilizza il browser runner di WebdriverIO, è importante notare che le finestre di dialogo che bloccano il thread come alert o confirm non possono essere utilizzate nativamente. Questo perché bloccano la pagina web, il che significa che WebdriverIO non può continuare a comunicare con la pagina, causando il blocco dell'esecuzione.

In tali situazioni, WebdriverIO fornisce mock predefiniti con valori di ritorno predefiniti per queste API. Ciò garantisce che se l'utente utilizza accidentalmente API web di popup sincrone, l'esecuzione non si blocchi. Tuttavia, si consiglia comunque all'utente di simulare queste API web per una migliore esperienza. Leggi di più in Mocking.

Examples

Assicurati di controllare la documentazione sul component testing e dai un'occhiata al repository di esempio per esempi che utilizzano questi e vari altri framework.

Welcome! How can I help?

WebdriverIO AI Copilot