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.

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

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.