Runner

Um runner no WebdriverIO organiza como e onde os testes são executados ao usar o testrunner. Atualmente, o WebdriverIO suporta dois tipos diferentes de runner: runner local e runner de navegador.

Runner Local

O Runner Local inicia seu framework (por exemplo, Mocha, Jasmine ou Cucumber) dentro de um processo worker e executa todos os seus arquivos de teste dentro do seu ambiente Node.js. Cada arquivo de teste é executado em um processo worker separado por capacidade, permitindo máxima concorrência. Cada processo worker usa uma única instância de navegador e, portanto, executa sua própria sessão de navegador, permitindo o máximo de isolamento.

Como cada teste é executado em seu próprio processo isolado, não é possível compartilhar dados entre arquivos de teste. Existem duas maneiras de contornar isso:

• usar o @wdio/shared-store-service para compartilhar dados entre todos os workers
• agrupar arquivos de especificação (leia mais em Organizing Test Suite)

Se nada mais for definido no wdio.conf.js, o Runner Local é o runner padrão no WebdriverIO.

Instalação

Para usar o Runner Local, você pode instalá-lo via:

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

Configuração

O Runner Local é o runner padrão no WebdriverIO, então não há necessidade de defini-lo dentro do seu wdio.conf.js. Se você quiser configurá-lo explicitamente, pode defini-lo da seguinte forma:

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

Runner de Navegador

Ao contrário do Runner Local, o Runner de Navegador inicia e executa o framework dentro do navegador. Isso permite que você execute testes unitários ou de componentes em um navegador real, em vez de em um JSDOM, como muitos outros frameworks de teste.

Embora o JSDOM seja amplamente utilizado para fins de teste, no final das contas, não é um navegador real nem permite emular ambientes móveis. Com este runner, o WebdriverIO permite que você execute facilmente seus testes no navegador e use comandos WebDriver para interagir com elementos renderizados na página.

Aqui está uma visão geral da execução de testes no JSDOM versus o Runner de Navegador do WebdriverIO:

	JSDOM	WebdriverIO Browser Runner
1.	Executa seus testes dentro do Node.js usando uma reimplementação dos padrões da web, notadamente os padrões WHATWG DOM e HTML	Executa seu teste em um navegador real e roda o código em um ambiente que seus usuários utilizam
2.	Interações com componentes só podem ser imitadas via JavaScript	Você pode usar a API WebdriverIO para interagir com elementos através do protocolo WebDriver
3.	O suporte ao Canvas requer dependências adicionais e tem limitações	Você tem acesso à verdadeira API Canvas
4.	JSDOM tem algumas ressalvas e APIs Web não suportadas	Todas as APIs Web são suportadas, pois os testes são executados em um navegador real
5.	Impossível detectar erros entre navegadores	Suporte para todos os navegadores, incluindo navegadores móveis
6.	Não pode testar estados de pseudo-elementos	Suporte para estados de pseudo-elementos como :hover ou :active

Este runner usa o Vite para compilar seu código de teste e carregá-lo no navegador. Ele vem com presets para os seguintes frameworks de componentes:

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

Cada arquivo de teste / grupo de arquivos de teste é executado dentro de uma única página, o que significa que entre cada teste a página é recarregada para garantir o isolamento entre os testes.

Instalação

Para usar o Runner de Navegador, você pode instalá-lo via:

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

Configuração

Para usar o Runner de Navegador, você deve definir uma propriedade runner dentro do seu arquivo wdio.conf.js, por exemplo:

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

Opções do Runner

O Runner de Navegador permite as seguintes configurações:

preset

Se você testa componentes usando um dos frameworks mencionados acima, pode definir um preset que garante que tudo seja configurado automaticamente. Esta opção não pode ser usada junto com viteConfig.

Tipo: vue | svelte | solid | react | preact | stencil
Exemplo:

wdio.conf.js

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

viteConfig

Defina sua própria configuração Vite. Você pode passar um objeto personalizado ou importar um arquivo vite.conf.ts existente se usar o Vite.js para desenvolvimento. Observe que o WebdriverIO mantém configurações Vite personalizadas para configurar o ambiente de teste.

Tipo: string ou UserConfig ou (env: ConfigEnv) => UserConfig | Promise<UserConfig>
Exemplo:

wdio.conf.ts

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

export const {
    // ...
    runner: ['browser', { viteConfig }],
    // ou simplesmente:
    runner: ['browser', { viteConfig: '../vites.config.ts' }],
    // ou use uma função se sua configuração vite contiver muitos plugins
    // que você só quer resolver quando o valor for lido
    runner: ['browser', {
        viteConfig: () => ({
            // ...
        })
    }],
    // ...
}

headless

Se definido como true, o runner atualizará as capacidades para executar testes sem interface gráfica. Por padrão, isso é habilitado em ambientes CI onde uma variável de ambiente CI é definida como '1' ou 'true'.

Tipo: boolean
Padrão: false, definido como true se a variável de ambiente CI estiver definida

rootDir

Diretório raiz do projeto.

Tipo: string
Padrão: process.cwd()

coverage

O WebdriverIO suporta relatórios de cobertura de teste através do istanbul. Veja Opções de Cobertura para mais detalhes.

Tipo: object
Padrão: undefined

Opções de Cobertura

As seguintes opções permitem configurar os relatórios de cobertura.

enabled

Habilita a coleta de cobertura.

Tipo: boolean
Padrão: false

include

Lista de arquivos incluídos na cobertura como padrões glob.

Tipo: string[]
Padrão: [**]

exclude

Lista de arquivos excluídos da cobertura como padrões glob.

Tipo: string[]
Padrão:

[
  '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 de extensões de arquivo que o relatório deve incluir.

Tipo: string | string[]
Padrão: ['.js', '.cjs', '.mjs', '.ts', '.mts', '.cts', '.tsx', '.jsx', '.vue', '.svelte']

reportsDirectory

Diretório para onde escrever o relatório de cobertura.

Tipo: string
Padrão: ./coverage

reporter

Relatores de cobertura a serem usados. Veja a documentação do istanbul para uma lista detalhada de todos os relatores.

Tipo: string[]
Padrão: ['text', 'html', 'clover', 'json-summary']

perFile

Verifica os limiares por arquivo. Veja lines, functions, branches e statements para os limiares reais.

Tipo: boolean
Padrão: false

clean

Limpa os resultados de cobertura antes de executar os testes.

Tipo: boolean
Padrão: true

lines

Limiar para linhas.

Tipo: number
Padrão: undefined

functions

Limiar para funções.

Tipo: number
Padrão: undefined

branches

Limiar para ramos.

Tipo: number
Padrão: undefined

statements

Limiar para declarações.

Tipo: number
Padrão: undefined

Limitações

Ao usar o runner de navegador do WebdriverIO, é importante observar que diálogos de bloqueio de thread como alert ou confirm não podem ser usados nativamente. Isso ocorre porque eles bloqueiam a página da web, o que significa que o WebdriverIO não pode continuar se comunicando com a página, fazendo com que a execução fique travada.

Nessas situações, o WebdriverIO fornece mocks padrão com valores de retorno padrão para essas APIs. Isso garante que, se o usuário acidentalmente usar APIs de popup web síncronas, a execução não ficará travada. No entanto, ainda é recomendável que o usuário faça mock dessas APIs web para uma melhor experiência. Leia mais em Mocking.

Exemplos

Certifique-se de verificar a documentação sobre testes de componentes e dê uma olhada no repositório de exemplos para exemplos usando esses e vários outros frameworks.