WebDriver 4 + Mocha + Chai

O que é o Selenium WebDriver 4?

Padrão W3C WebDriver para automação de browsers — controla Chrome, Firefox e Safari via protocolo HTTP, com bindings em várias linguagens.

• Selenium 4 — API unificada, Selenium Manager gerencia drivers
• Pacote npm selenium-webdriver — cliente oficial para Node.js
• Neste projeto: Chrome headless via Builder().forBrowser('chrome')
• TestFlow na porta 5050 — mesma app dos suites Cypress/Playwright
• Screenshots on failure, Allure report, tags Mocha (@smoke, @regression)

Por que Mocha + Chai?

Pré-requisitos

Instalação — testflow-selenium

1. Clone e instale
   git clone https://github.com/lflucasferreira/testflow-selenium.git
cd testflow-selenium && npm install
2. Configure env (opcional)
   cp .env.example .env — BASE_URL, HEADLESS, credenciais demo
3. Suba TestFlow
   docker run -p 5050:5050 qaschool/testflow:latest
4. Rode os testes
   npm test · npm run test:smoke · npm run test:api

Estrutura do projeto

testflow-selenium/
├── .mocharc.cjs          # Mocha + Allure/mochawesome
├── config/env.js         # BASE_URL, headless, credenciais
├── support/
│   ├── driver.js         # Builder + Chrome options
│   ├── helpers.js        # getByTestId, waits, screenshots
│   ├── auth.js           # loginViaApi, visitWithSession
│   └── api.js            # fetch + publicRequest
├── pages/                # Page Object Model
├── tests/                # 11 arquivos *.test.js
│   └── hooks.js          # beforeAll/afterEach global
└── scripts/              # wd-run.sh, Allure, Pages

Configuração — driver & Mocha

// support/driver.js
const driver = await new Builder()
  .forBrowser('chrome')
  .setChromeOptions(options)  // --headless=new, window-size
  .build()

// .mocharc.cjs
module.exports = {
  require: ['tests/hooks.js'],
  timeout: 120000,
  reporter: process.env.CI ? 'allure-mocha' : 'mochawesome',
  spec: 'tests/**/*.test.js',
}

tests/hooks.js cria o WebDriver uma vez, expõe getHelpers() global e tira screenshot em falha.

Seu primeiro teste

// tests/auth/login.test.js
const LoginPage = require('../../pages/LoginPage')
const { getConfig } = require('../../support/driver')

describe('Authentication @regression', function () {
  beforeEach(async function () {
    const helpers = getHelpers()
    await clearSession(helpers)
    loginPage = new LoginPage(helpers)
    await loginPage.open()
  })

  it('logs in via UI and redirects to dashboard @smoke @critical', async function () {
    const config = getConfig()
    await loginPage.loginWith(config.demoEmail, config.demoPassword)
    await loginPage.shouldRedirectToDashboard()
  })
})

Cobertura da suíte — 11 arquivos

Sem suites de a11y (axe), regressão visual ou component testing isolado — foco em E2E browser + API REST.

Allure Report

npm run test:smoke
npm run report:allure
npm run report:allure:open

# CI publica em GitHub Pages
npm run pages:prepare-allure

CI — selenium.yml

Service container qaschool/testflow:latest · health check /health · artefatos de screenshot e allure-results em falha.

Boas práticas

• Page Objects — locators data-testid centralizados em helpers.js
• visitWithSession no beforeEach — specs focam na feature
• getByTestId — explicit wait antes de interagir
• BASE_URL via config/env.js — não hardcode localhost
• API tests com fetch nativo + validação JSON Schema (Ajv)
• Smoke, regression e full suite em paralelo no CI
• Tags Mocha — filtrar @smoke, @api nos scripts npm
• IDs rastreáveis [TC-xxxx] em support/enums/testCases.js
• Um cenário por it() — falhas legíveis no Allure