Docker контейнеризация тестов

Использование Docker для контейнеризации тестов позволяет упростить настройку и запуск тестовых окружений. Это особенно полезно в контексте автоматизированного тестирования, где стабильность и предсказуемость окружения имеют критическое значение. В контексте WebdriverIO, Docker предоставляет средство для изоляции тестов, устранения зависимости от локальных конфигураций и обеспечения идентичных условий для каждого запуска.

Преимущества использования Docker

  1. Изоляция тестового окружения: Тесты запускаются в полностью изолированном контейнере, что гарантирует отсутствие вмешательства со стороны других процессов или приложений на хостовой машине.

  2. Портируемость: Контейнеры Docker могут быть легко перенесены между различными системами (например, с локального компьютера на сервер CI/CD) без изменений в конфигурации.

  3. Автоматизация и повторяемость: Создание контейнеризированного окружения позволяет автоматизировать процесс установки зависимостей и настройки окружения. Это особенно полезно при интеграции с системами непрерывной интеграции.

  4. Согласованность среды: С Docker обеспечивается одинаковое тестовое окружение для всех участников проекта (разработчиков, тестировщиков, серверов CI), что исключает проблемы с несовместимостью сред.

Основные компоненты Docker для тестирования

Для использования Docker с WebdriverIO необходимо настроить несколько ключевых компонентов:

  1. Dockerfile: Это файл, который описывает, как должен быть построен контейнер. Он включает инструкции по установке необходимых зависимостей, настройке окружения и запуску тестов.

  2. docker-compose.yml: С помощью этого файла можно настроить многоконтейнерные приложения. Для тестов WebdriverIO можно использовать контейнеры для браузеров (например, для Chrome или Firefox) и контейнер для запуска самого WebdriverIO.

  3. WebdriverIO: В Docker-контейнере будет установлен WebdriverIO, а также все зависимости, такие как драйверы для браузеров (например, ChromeDriver) и специфические плагины для работы с браузерными контейнерами.

Структура проекта

Для настройки Docker с WebdriverIO обычно используется следующая структура проекта:

project-root/
├── docker/
│   ├── Dockerfile
│   └── docker-compose.yml
├── tests/
│   └── test.spec.js
├── wdio.conf.js
└── package.json
  • Dockerfile: Здесь описывается создание контейнера для WebdriverIO.
  • docker-compose.yml: Управляет многоконтейнерной инфраструктурой для запуска браузеров и тестов.
  • wdio.conf.js: Конфигурация для WebdriverIO.
  • test.spec.js: Пример теста, который будет выполнен внутри Docker-контейнера.

Создание Dockerfile для WebdriverIO

Первым шагом является создание Dockerfile, который будет содержать инструкции для создания контейнера. Пример простого Dockerfile для WebdriverIO:

# Используем официальный Node.js образ в качестве базового
FROM node:16

# Устанавливаем зависимости
RUN apt-get update && apt-get install -y \
  wget \
  curl \
  unzip \
  && rm -rf /var/lib/apt/lists/*

# Устанавливаем Chrome и ChromeDriver
RUN wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
RUN dpkg -i google-chrome-stable_current_amd64.deb
RUN apt-get install -f -y

# Устанавливаем WebDriverIO
WORKDIR /app
COPY package.json /app/
RUN npm install

# Копируем тесты
COPY ./tests /app/tests

# Запускаем тесты
CMD ["npx", "wdio", "wdio.conf.js"]

Этот Dockerfile выполняет следующие шаги:

  1. Использует Node.js как базовый образ.
  2. Устанавливает необходимые зависимости, такие как браузер Chrome и ChromeDriver.
  3. Копирует проект и установленные пакеты через npm install.
  4. Определяет команду для запуска тестов с помощью WebdriverIO.

Настройка docker-compose.yml

Для упрощения запуска контейнеров и настройки взаимодействия между контейнерами создается файл docker-compose.yml. Это позволяет запускать тесты на удаленном браузере, таком как Chrome, внутри контейнера.

Пример файла docker-compose.yml:

version: '3'
services:
  selenium:
    image: selenium/standalone-chrome:latest
    ports:
      - "4444:4444"
    environment:
      - SE_NODE_MAX_SESSIONS=1
      - SE_OPTS="-browserTimeout 300 -timeout 300"

  web:
    build: ./docker
    depends_on:
      - selenium
    environment:
      - SELENIUM_HOST=selenium
    volumes:
      - ./tests:/app/tests
    ports:
      - "3000:3000"
    command: ["npx", "wdio", "wdio.conf.js"]

В этом примере используется сервис selenium для запуска браузера Chrome в контейнере. Это позволяет WebdriverIO тестам, запущенным в сервисе web, подключаться к Selenium серверу и выполнять тесты в браузере.

Конфигурация WebdriverIO

Файл wdio.conf.js необходим для настройки WebdriverIO. В нем указывается адрес Selenium сервера, а также конфигурации для драйвера и других параметров.

Пример конфигурации:

exports.config = {
  runner: 'local',
  specs: [
    './tests/**/*.js'
  ],
  capabilities: [{
    maxInstances: 1,
    browserName: 'chrome',
    'goog:chromeOptions': {
      args: ['--headless', '--no-sandbox', '--disable-gpu']
    }
  }],
  services: ['selenium-standalone'],
  seleniumArgs: {
    drivers: {
      chrome: { version: 'latest' }
    }
  },
  seleniumInstallArgs: {
    drivers: {
      chrome: { version: 'latest' }
    }
  },
  baseUrl: 'http://localhost:3000',
  logLevel: 'info',
  framework: 'mocha',
  reporters: ['spec'],
  mochaOpts: {
    timeout: 60000
  }
};

Здесь конфигурируется:

  • capabilities: Настройки для браузера (Chrome), включая аргументы для работы в headless-режиме.
  • services: Указывает, что используется сервис Selenium для запуска браузера.
  • baseUrl: Адрес веб-приложения, с которым будут взаимодействовать тесты.

Запуск тестов с Docker

После того как все настройки готовы, запуск тестов осуществляется через Docker Compose:

docker-compose up --build

Эта команда создает и запускает контейнеры, а затем WebdriverIO выполняет тесты на браузере внутри контейнера Selenium.

Заключение

Docker значительно упрощает процесс автоматизации тестирования в WebdriverIO, обеспечивая стабильность и переносимость тестовых окружений. Создание изолированных контейнеров с нужными зависимостями позволяет избежать проблем с конфигурацией и гарантировать одинаковые условия для всех участников разработки.