Непрерывная интеграция — Тестирование с Playwright

• Как работает CI для Playwright?
  • Github Actions
  • Gitlab CI
• Отладка запуска
• Конфигурация
• Ускорение запуска

Непрерывная интеграция (CI) - процесс, который автоматически запускает разнообразные проверки качества кода по git-событиям, например, коммиту, отправке пулреквеста или созданию тега. В такие проверки входят анализ стиля кода с помощью линтеров, запуск тестов и даже анализ на безопасность.

Для реализации CI пользуются готовыми решениями. Начиная от SaaS-сервисов до систем, которые устанавливаются к себе на сервера. Среди них наиболее популярными считаются Github Actions (SaaS), Gitlab CI (SaaS/Self-hosted) и Jenkins (self-hosted). Все они работают по одному и тому же принципу: изменения в коде => запускаем проверки => шлем отчет.

Разработчик -> Git push -> CI запускает линтер и тестирование ->
  -> Если успешно -> Слияние изменений
  -> Если неуспешно -> Логирование ошибок и уведомление команды

Из этого, кстати, следует один вывод. Для работы такой системы нужно чтобы тесты и код находились в одном репозитории. Только тогда изменение в тестах или в коде будут отрабатывать. Для реализации более сложных конфигураций, когда тесты и код находятся в разных местах есть свои подходы, но это остается за рамками урока.

Как работает CI для Playwright?

Процесс автоматического тестирования с Playwright в CI можно представить так:

[Разработчик] --push--> [CI сервер] --запуск--> [Проект] --подготовка-->
[Линтер] --проверка--> [Тесты] --результат--> [✅ Успех / ❌ Ошибка]

Для его настройки обычно нужно выполнить два шага:

1. Зарегистрироваться в сервисе CI и завести там проект подключив репозиторий.
2. Настроить конфигурацию CI в специальном файле внутри вашего репозитория.

Первый шаг нужен только в том случае, если вы используете стороннюю по отношению к хранилищу проекта систему, например, Jenkins. Если же CI это часть платформы хранения кода, то шаг пропускается. В первую очередь это относится к Github Actions и Gitlab CI, для них достаточно создать правильный файл и закоммитить его. Дальше все работает автоматически.

Github Actions

Проекты расположенные на Github могут воспользоваться Github Actions, который доступен из коробки. Только учтите, что для закрытых проектов он платный и стоимость зависит от нагрузки (количество запусков и другие параметры) на их систему. Но есть и хорошая новость. Github Actions позволяет подключить свою машину, на которой будут выполняться проверки. В таком случае платить придется только за свой сервер, а Github Actions обеспечит весь процесс бесплатно. Например, так устроено тестирование практических заданий на Хекслете.

Для подключения Github Actions достаточно создать файл .github/workflows/playwright.yml внутри вашего проекта. Ниже приведена базовая структура, которую можно и даже нужно менять под себя.

name: Playwright Tests
# Запускаем на каждый коммит в main и на пулреквесты в main
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  test:
    timeout-minutes: 60
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4 # Скачиваем код
      - uses: actions/setup-node@v4 # Настраиваем правильное окружение
        with:
          node-version: lts/*
      - name: Install dependencies
        run: npm ci # Устанавливаем зависимости
      - name: Install Playwright Browsers
        run: npx playwright install --with-deps # Ставим нужные браузеры
      - name: Run Playwright tests
        run:
          npx playwright test # Запускаем тесты
          # Заливаем отчет в Github Actions, откуда его можно скачать и изучить
      - uses: actions/upload-artifact@v4
        if: ${{ !cancelled() }}
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

Процесс подготовки тестового окружения и его запуска не отличается от локального использования. Мы так же устанавливаем зависимости, скачиваем нужные браузеры и запускаем тесты. Ситуация будет другой, если тестируемый проект требует своей настройки и запуска. В таком случае в этом файле нужно добавить команды для его подготовки к тестированию.

Gitlab CI

Для подключения Gitlab CI нужно в корне проекта создать файл .gitlab-ci.yml со следующим содержимым:

stages:
  - test

tests:
  stage: test
  image: mcr.microsoft.com/playwright:v1.50.1-noble
  script:
    - npm ci # Install project dependencies
    - npx playwright test # Run your Playwright tests
  allow_failure: true
artifacts:
  when: always
  paths:
    - playwright-report
  expire_in: 2 days

В случае с Gitlab CI используется Docker-образ, в котором предустановленны все основные браузеры, поэтому их не нужно ставить отдельно.

Отладка запуска

Playwright поддерживает переменную окружения DEBUG, которая включает вывод логов Playwright во время запуска браузеров. Ее удобно использовать в том случае, если видны какие-то проблемы старта, которые не очевидно как решать.

DEBUG=pw:browser npx playwright test

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

Во время инициализации Playwright проекта, в файле конфигурации заранее создаются настройки, полезные для запуска на CI:

// playwright.config.js
export default defineConfig({
  // Остальная конфигурация
  /* Fail the build on CI if you accidentally left test.only in the source code. */
  forbidOnly: !!process.env.CI,
  /* Retry on CI only */
  retries: process.env.CI ? 2 : 0,
  /* Opt out of parallel tests on CI. */
  workers: process.env.CI ? 1 : undefined,
  /* Reporter to use. See https://playwright.dev/docs/test-reporters */
  // reporter: process.env.CI ? 'github' : 'html',
})

Из интересного здесь включается механизм ретраев в случае падения тестов. Он нужен для уменьшения количества ложных срабатываний. Такое нередко происходит в e2e-тестах из-за их хрупкости. Вполне вероятно что повторный запуск пройдет хорошо, если, например, первый упал по таймауту.

По умолчанию тесты на CI запускаются на одном воркере. Это снижает скорость выполнения, но дает более высокую предсказуемость результата и меньшее количество плавающих ошибок, когда, то работает, то не работает.

Ускорение запуска

E2E-тесты требуют много ресурсов для запуска и работы, поэтому эти тесты самые медленные среди всех видов тестов. Запуск даже не очень большого набора тестов может занимать минуты и десятки минут. На крупных проектов время доходит до многих часов. В такой ситуации запускать весь набор тестов на каждый коммит не получится. Придется слишком долго ждать.

Этот процесс можно оптимизировать с помощью механизма Fail Fast. В таком случае на каждый коммит будут запускаться только измененные тесты, а не весь набор. Для его включения нужно заменить команду запуска тестов.

name: Playwright Tests
on:
  push:
    branches: [main]
jobs:
  test:
    timeout-minutes: 60
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          # Force a non-shallow checkout, so that we can reference $GITHUB_BASE_REF.
          # See https://github.com/actions/checkout for more details.
          fetch-depth: 0
      - uses: actions/setup-node@v4
        with:
          node-version: lts/*
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright Browsers
        run: npx playwright install --with-deps
      - name: Run changed Playwright tests
        run: npx playwright test --only-changed=$GITHUB_BASE_REF
      - uses: actions/upload-artifact@v4
        if: ${{ !cancelled() }}
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

Это не на 100% надежный механизм с точки зрения определения того что поменялось, но он достаточен. Полный запуск тестов в любом случае должен происходить, например, на пулреквест или просто по расписанию.

Самостоятельная работа

Повторите шаги из урока настроив CI в репозитории

1. Добавьте конфигурацию для запуска CI в Github
2. Создайте репозиторий в Github, если этого еще не сделали, и запушьте изменения
3. Проверьте, что формируется отчет и загружается в артефакты

Дополнительные материалы

1. Официальная документация
2. Пример настроенного проекта Playwright Example (Исходный код)