Привет, я Лиза – веб разработчик в одной зарубежной компании. Хочу поделиться тем, как я автоматизировала регрессионное тестирование в рабочем проекте на React с использованием довольно нового фреймворка Playwright. Разберемся, почему именно этот фреймворк, какие подводные камни, как обойти авторизацию и кто этим пользуется.
Зачем нужны end-to-end тесты
End-to-end (e2e) тестирование — это способ убедиться, что каждый шаг, который пользователь делает, и все изменения данных проходят без проблем. Оно не заменяет другие виды тестирования, а, наоборот, дополняет их, обеспечивая комплексную проверку функциональности, производительности и стабильности всего приложения.
В нашем проекте изначально использовались только юнит тесты и то, не в активном режиме и необязательные. QA тестировщика тоже не было, а потребность в тестировании всего приложения была и хотелось автоматизировать важные базовые флоу для регрессионного тестирования.
Почему Playwright
Playwright – это фреймворк с открытым исходным кодом для автоматизации тестирования конечного пользователя. Он поддерживает большинство современных браузеров, включая Firefox, Chromium и Webkit с использованием единого API. Playwright создан и поддерживается компанией Microsoft и постепенно завоевывает популярность.
Также удобно, что Playwright поддерживает Jest, Mocha, Jasmine и другие известные серверы непрерывной интеграции и предоставляет поддержку различных языков программирования, включая TypeScript, JavaScript, Python, .NET и Java.
Сравнение с другими фреймворками
Я сравнивала этот фреймворк с другими фреймворками для тестирования, такими как Puppeteer, Cypress и WebDriverIO. Именно они были выбраны в качестве кандидатов из-за их широкой популярности как на рынке, так и в моей компании.
Как можно заметить, Puppeteer не поддерживает тестирование в Safari, что было критичном фактором для выбора фреймворка в нашем проекте. Cypress использует Mocha.js, а также не является оптимальным вариантом, поскольку не поддерживает тестирование end-to-end для iOS. Кроме того, экспериментальная поддержка Safari в Cypress была бы недостаточной из-за отсутствия некоторых функций и известных ошибок (могут быть затронуты захват событий и навигация по сайту).
В сравнении WebdriverIO и Playwright решающими факторами стали скорость, поддержка записи видео и подержанные языки приложения.
Кроме того, анализируя тенденции установки через Npm, видно, что количество установок Playwright недавно превысило количество установок WebdriverIO. Эта тенденция может говорить о том, что Playwright, скорее всего, станет будущим лидером среди фреймворков для многобраузерного e2e тестирования веб-приложений, что в свою очередь приведет к увеличению числа разработчиков и комьюнити.
Дополнительным решающим фактором было то, что у нас в проекте уже были написаны unit тесты на Jest до этого, а у Playwright есть beta поддержка компонентного тестирования. С его использованием появилась бы возможность перевести unit тесты на тот же фреймворк и дебажить в настоящем браузере с брейкпоинтами вместо виртуального DOM-дерева в случае с Jest.
Подготовка проекта
Приняли решение использовать Playwright для e2e и потенциально компонентного тестирования, что дальше?
Настройка для end-to-end тестирования
Для полноценного тестирования нужно установить библиотеку playwright как в документации. Мы используем yarn
yarn create playwrightЧто будет скачано:
playwright.config.ts
package.json
package-lock.json
tests/
example.spec.ts
tests-examples/
demo-todo-app.spec.tsОдной из важных деталей здесь является playwright.config.ts. В этом файле можно конфигурировать запуск тестов непосредственно под ваш проект и нужды.
Например, настроить браузеры (в нашем случае только Chrome):
projects: [
{
name: 'chromium',
use: { ...devices['Desktop Chrome'] },
},
],Настроить конкретный URL, если нужно ходить не локально в проект:
use: {
trace: 'on-first-retry',
baseURL: process.env.PLAYWRIGHT_URL ?? 'http://localhost:1234',
},Выставить таймаут, который будет выполняться перед каждой проверкой в тестах:
expect: {
timeout: 5000,
},Настройка для компонентного тестирования (beta)
Описана в отдельном разделе документации.
Для установки нужно выполнить следующие команды:
yarn create playwright --ct
yarn add @playwright/experimental-ct-reactЗдесь я обнаружила первую проблему: компонентное тестирование предполагает, что в проекте установлен React 18 (баг). В нашем версия 17, поэтому устанавливать нужно
yarn add @playwright/experimental-ct-react17Файл конфигурации для компонентного тестирования лучше завести отдельный и настроить там другой путь для юнит тестов, чтобы не путать с end-to-end.
Написание тестов
Далее, если всё пошло так, можно начать писать тесты.
Пример полноценного dummy теста:
import { test, expect } from '@playwright/test';
test('get started link', async ({ page }) => {
await page.goto('https://playwright.dev/');
await page.getByRole('link', { name: 'Get started' }).click();
await expect(page.getByRole('heading', { name: 'Installation' })).toBeVisible();
});Запускаем
npx playwright test --uiС параметром --ui тесты откроются в отдельном интерфейсном окне. В нем помимо запуска тестов, можно останавливать их в любом месте, специальным locator picker’ом выбирать любой элемент страницы, смотреть выполнение теста по шагам в удобном таймлайне. Я не работала в таких режимах с другими тестами, так что мне просто очень нравится этот. Пример интерфейса беру из документации в целях сохранения приватности нашего проекта.
Обработка проблем
Что после этого может пойти не так? Рассмотрим несколько проблем, с которыми мне пришлось столкнуться. Имеющийся легаси код повлек за собой: невозможность использования .js файлов, с имеющимся в них JSX кодом, а также файлов и компонент, в которых есть дефолтный экспорт.
Первую проблему с .js разрешением файлов можно решить, добавив настройку в конфиг:
/* Vite config */
ctViteConfig: {
optimizeDeps: {
force: true,
esbuildOptions: {
loader: {
'.js': 'jsx',
},
},
},
},Подобные настройки подходят для проектов, которые используют Vite сервер. Внутрь ctViteConfig можно добавлять и другие конструкции, которые могут помочь с компонентным тестированием. Я пробовала настроить его для второй проблемы с дефолтными экспортами, но пока что единственным решением стало механическое изменение каждого дефолтного экспорта на именованный.
Двойная Google аутентификация
Второй более серьезной проблемой стала двойная аутентификация, которая есть у нас в проекте и нужна была для открытия приложения в тестах. Двойная аутентификация подразумевает, что после ввода данных в Гугл форму, нужно затем вторым способом подтвердить свою личность, в нашем случае с телефона. А это в свою очередь значит, что полностью автоматизировать тесты (интегрировать их в CI/CD) таким образом будет невозможно.
Возможные обходные решения:
делать моки запросы с бэкенда, чтобы не требовалось аутентификации для их выполнения (но тогда это нечестный end-to-end);
создать тестового пользователя и отключить у него двойную аутентификацию (это оказалось сложно из-за специфики проекта);
попытаться сохранить токен авторизации конкретного пользователя в локальный .env файл и не коммитить его в репозиторий (тут нарушается приватность конкретного живого пользователя с его данными);
создать отдельное окружение на бэкенде конкретно под тесты с облегченными запросами (может быть сложно и времязатратно).
В нашем случае оказалось, что кто-то в проекте ранее уже сделал обходной путь с созданием временного пользователя с необходимыми для запросов данными, под которым можно заходить без авторизации. Так появилась надежда, что запуск тестов можно внедрять в CI на Github.
Интеграция с CI/CD
Данный этап пока в процессе реализации из-за специфики проекта и вопроса необходимости запуска всех тестов на каждом пулл реквесте. Преимущества в такой интеграции для задач средней и высокой сложности точно есть: регрессионные тесты будут проходить все базовые флоу и снизится количество незамеченных ошибок, багов в продакшн коде и инцидентов.
Возможности внедрения тоже существуют, например, запускать тест кейсы на уже собранном в CI стенде с кодом ветки конкретного пулл реквеста. Но пока больше информации можно найти здесь. Мы на данном этапе запускаем тесты локально при добавлении нового функционала, и это действительно влияет в лучшую сторону на проект, к тому же помогает нам самим лучше ориентироваться в логике и добавлять больше покрытия.
Помимо этого, можно также переписывать существующие на Jest юнит тесты на Playwright, чтобы иметь возможность визуально смотреть на отдельные компоненты и дебажить настоящее DOM-дерево, вместо виртуального.
Полезные советы и рекомендации
Для меня это был первый опыт внедрения фреймворка для тестирования в проект с нуля. С помощью большого количества ресерча, гугления, общения с людьми из команды и компании в целом, я смогла прийти к примерному пониманию куда двигаться.
Уверена, что для каждого проекта свой подход, свои технологии, так что думаю изначально можно опираться на следующие вещи:
совместимость с вашим технологическим стеком
поддержка браузеров и платформ
скорость выполнения тестов
сообщество и поддержка
Надеюсь, мой опыт вдохновит других разработчиков рассмотреть Playwright как фреймворк для тестирования. В конце концов, наша цель как разработчиков – создавать приложения, которыми легко и приятно пользоваться, а качественное тестирование – это один из ключей к достижению этой цели.
Больше о веб-разработке и жизни в Лондоне в моем телеграм канале https://t.me/lizas_sweets.
Источники и дополнительные материалы
25 причин выбрать Playwright https://marcusfelling.com/blog/2022/25-reasons-to-choose-playwright-as-your-next-web-testing-framework/
Playwright документация https://playwright.dev/docs
Гайд по компонентному тестированию https://testgrid.io/blog/playwright-component-testing/
Google аутентификация с Playwright https://adequatica.medium.com/google-authentication-with-playwright-8233b207b71a
Познавательные видео на Youtube от создателей Playwright https://www.youtube.com/@Playwrightdev/videos
Гайд по UI mode https://habr.com/en/companies/otus/articles/757630/
