Runner

Un runner dans WebdriverIO orchestre comment et où les tests sont exécutés lors de l'utilisation du testrunner. WebdriverIO prend actuellement en charge deux types différents de runners : le runner local et le runner de navigateur.

Runner Local

Le Runner Local initialise votre framework (par exemple Mocha, Jasmine ou Cucumber) dans un processus de travail et exécute tous vos fichiers de test dans votre environnement Node.js. Chaque fichier de test est exécuté dans un processus de travail distinct par capacité, permettant une concurrence maximale. Chaque processus de travail utilise une seule instance de navigateur et exécute donc sa propre session de navigateur, permettant une isolation maximale.

Étant donné que chaque test est exécuté dans son propre processus isolé, il n'est pas possible de partager des données entre les fichiers de test. Il existe deux façons de contourner ce problème :

utiliser le @wdio/shared-store-service pour partager des données entre tous les workers
regrouper les fichiers de spécification (en savoir plus dans Organisation de la suite de tests)

Si rien d'autre n'est défini dans le wdio.conf.js, le Runner Local est le runner par défaut dans WebdriverIO.

Installation

Pour utiliser le Runner Local, vous pouvez l'installer via :

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

Configuration

Le Runner Local est le runner par défaut dans WebdriverIO, il n'est donc pas nécessaire de le définir dans votre wdio.conf.js. Si vous souhaitez le définir explicitement, vous pouvez le faire comme suit :

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

Runner de Navigateur

Contrairement au Runner Local, le Runner de Navigateur initialise et exécute le framework dans le navigateur. Cela vous permet d'exécuter des tests unitaires ou des tests de composants dans un navigateur réel plutôt que dans un JSDOM comme de nombreux autres frameworks de test.

Bien que JSDOM soit largement utilisé à des fins de test, ce n'est finalement pas un véritable navigateur et vous ne pouvez pas émuler des environnements mobiles avec lui. Avec ce runner, WebdriverIO vous permet d'exécuter facilement vos tests dans le navigateur et d'utiliser les commandes WebDriver pour interagir avec les éléments rendus sur la page.

Voici un aperçu de l'exécution de tests dans JSDOM par rapport au Runner de Navigateur WebdriverIO

	JSDOM	WebdriverIO Browser Runner
1.	Exécute vos tests dans Node.js en utilisant une réimplémentation des standards web, notamment les standards WHATWG DOM et HTML	Exécute votre test dans un navigateur réel et exécute le code dans un environnement que vos utilisateurs utilisent
2.	Les interactions avec les composants ne peuvent être imitées que via JavaScript	Vous pouvez utiliser l'API WebdriverIO pour interagir avec les éléments via le protocole WebDriver
3.	Le support Canvas nécessite des dépendances supplémentaires et a des limitations	Vous avez accès à la véritable API Canvas
4.	JSDOM a certaines mises en garde et des API Web non prises en charge	Toutes les API Web sont prises en charge car les tests s'exécutent dans un navigateur réel
5.	Impossible de détecter les erreurs entre navigateurs	Prise en charge de tous les navigateurs, y compris les navigateurs mobiles
6.	Ne peut pas tester les états pseudo des éléments	Prise en charge des états pseudo tels que `:hover` ou `:active`

Ce runner utilise Vite pour compiler votre code de test et le charger dans le navigateur. Il est livré avec des préréglages pour les frameworks de composants suivants :

React
Preact
Vue.js
Svelte
SolidJS
Stencil

Chaque fichier de test / groupe de fichiers de test s'exécute dans une seule page, ce qui signifie qu'entre chaque test, la page est rechargée pour garantir l'isolation entre les tests.

Installation

Pour utiliser le Runner de Navigateur, vous pouvez l'installer via :

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

Configuration

Pour utiliser le Runner de Navigateur, vous devez définir une propriété runner dans votre fichier wdio.conf.js, par exemple :

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

Options du Runner

Le Runner de Navigateur permet les configurations suivantes :

`preset`

Si vous testez des composants utilisant l'un des frameworks mentionnés ci-dessus, vous pouvez définir un préréglage qui garantit que tout est configuré prêt à l'emploi. Cette option ne peut pas être utilisée avec viteConfig.

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

`viteConfig`

Définissez votre propre configuration Vite. Vous pouvez soit passer un objet personnalisé, soit importer un fichier vite.conf.ts existant si vous utilisez Vite.js pour le développement. Notez que WebdriverIO conserve des configurations Vite personnalisées pour configurer le harnais de test.

Type : string ou UserConfig ou (env: ConfigEnv) => UserConfig | Promise<UserConfig>
Exemple :

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

export const {
    // ...
    runner: ['browser', { viteConfig }],
    // ou simplement :
    runner: ['browser', { viteConfig: '../vites.config.ts' }],
    // ou utilisez une fonction si votre configuration vite contient beaucoup de plugins
    // que vous souhaitez résoudre uniquement lorsque la valeur est lue
    runner: ['browser', {
        viteConfig: () => ({
            // ...
        })
    }],
    // ...
}

`headless`

Si défini sur true, le runner mettra à jour les capacités pour exécuter les tests en mode headless. Par défaut, ceci est activé dans les environnements CI où une variable d'environnement CI est définie sur '1' ou 'true'.

Type : boolean
Défaut : false, défini sur true si la variable d'environnement CI est définie

`rootDir`

Répertoire racine du projet.

Type : string
Défaut : process.cwd()

`coverage`

WebdriverIO prend en charge les rapports de couverture de test via istanbul. Voir Options de couverture pour plus de détails.

Type : object
Défaut : undefined

Options de couverture

Les options suivantes permettent de configurer les rapports de couverture.

`enabled`

Active la collecte de couverture.

Type : boolean
Défaut : false

`include`

Liste des fichiers inclus dans la couverture sous forme de motifs glob.

Type : string[]
Défaut : [**]

`exclude`

Liste des fichiers exclus de la couverture sous forme de motifs glob.

Type : string[]
Défaut :

[
  '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 des extensions de fichiers que le rapport doit inclure.

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

`reportsDirectory`

Répertoire dans lequel écrire le rapport de couverture.

Type : string
Défaut : ./coverage

`reporter`

Rapporteurs de couverture à utiliser. Voir la documentation d'istanbul pour une liste détaillée de tous les rapporteurs.

Type : string[]
Défaut : ['text', 'html', 'clover', 'json-summary']

`perFile`

Vérifier les seuils par fichier. Voir lines, functions, branches et statements pour les seuils réels.

Type : boolean
Défaut : false

`clean`

Nettoyer les résultats de couverture avant d'exécuter les tests.

Type : boolean
Défaut : true

`lines`

Seuil pour les lignes.

Type : number
Défaut : undefined

`functions`

Seuil pour les fonctions.

Type : number
Défaut : undefined

`branches`

Seuil pour les branches.

Type : number
Défaut : undefined

`statements`

Seuil pour les déclarations.

Type : number
Défaut : undefined

Limitations

Lors de l'utilisation du runner de navigateur WebdriverIO, il est important de noter que les boîtes de dialogue bloquantes comme alert ou confirm ne peuvent pas être utilisées nativement. Cela est dû au fait qu'elles bloquent la page web, ce qui signifie que WebdriverIO ne peut pas continuer à communiquer avec la page, provoquant un blocage de l'exécution.

Dans de telles situations, WebdriverIO fournit des mocks par défaut avec des valeurs de retour par défaut pour ces API. Cela garantit que si l'utilisateur utilise accidentellement des API web de popup synchrones, l'exécution ne se bloquera pas. Cependant, il est toujours recommandé à l'utilisateur de mocker ces API web pour une meilleure expérience. En savoir plus dans Mocking.

Exemples

Assurez-vous de consulter la documentation sur les tests de composants et jetez un œil au dépôt d'exemples pour des exemples utilisant ces frameworks et divers autres.

Runner Local​

Installation​

Configuration​

Runner de Navigateur​

Installation​

Configuration​

Options du Runner​

preset​

viteConfig​

headless​

rootDir​

coverage​

Options de couverture​

enabled​

include​

exclude​

extension​

reportsDirectory​

reporter​

perFile​

clean​

lines​

functions​

branches​

statements​

Limitations​

Exemples​

Runner Local

Installation

Configuration

Runner de Navigateur

Installation

Configuration

Options du Runner

`preset`

`viteConfig`

`headless`

`rootDir`

`coverage`

Options de couverture

`enabled`

`include`

`exclude`

`extension`

`reportsDirectory`

`reporter`

`perFile`

`clean`

`lines`

`functions`

`branches`

`statements`

Limitations

Exemples