- Что такое Playwright
- Переходим к практике. Установка и настройка
- Туториал Playwright
- Советы и лучшие практики
- Миграция с Puppeteer
- Приложение: ответы на все вопросы по Playwright
Что такое Playwright
Playwright — NodeJS-фреймворк для headless-браузерного тестирования. Основной фокус — на скорости и производительности e2e-автотестов. У Playwright и Puppeteer сходные названия («драматург» и «кукловод»), что должно намекать, что Playwright создан бывшей командой Puppeteer.
Сначала картинки
Популярность судя по npm trends:
Знают о Playwright только половина опрошенных:
Пользуются — где-то 17%.
Каждый шестой — это много? Или мало?
А вот среди тех, кто пользовался, удовлетворенность неудержимо приближается к 100%:
Архитектура в одной картинке
Отличие в архитектуре от Selenium
Архитектура Selenium упрощенно:
Selenium работает по HTTP-протоколу, то есть после запуска теста весь его код, написанный тобой на любимом языке в Selenium Client Library (на рисунке слева), конвертируется в JSON-формат, далее отправляется в драйвер браузера (Server) через HTTP-протокол, и работает с браузером, то есть тестирует.
Архитектура Playwright упрощенно:
Playwright работает через протокол WebSocket, это значит что после запуска теста его код (тоже) конвертируется в JSON-формат и отправляется на сервер, (но) через WebSocket-протокол.
Разница между HTTP и WebSocket:
Подробнее:
Selenium отправляет каждую команду как отдельный HTTP-запрос и получает JSON-ответы. Таким образом, каждое действие (типа открытие браузера, нажатие элемента страницы, отправка текста из заполненной формы) — идет отдельным HTTP-запросом. Помимо того, после завершения каждого запроса подключение между сервером и клиентом будет закрыто; и должно быть снова открыто для отправки следующего запроса.
Это закрытие подключения после каждого запроса приводит к (иногда существенному) снижению скорости выполнения тестов, и «вводит слой возможной нестабильности» тестов.
Playwright же, отправляет-принимает все свои запросы через одно WebSocket-соединение, которое остается активным пока нужно, пока выполняются тесты. Что снижает количество «точек возможного отказа» и позволяет отправлять команды (то есть запросы) «пакетным способом», в одном подключении. Это быстрее и надежнее.
Плюсы
- Открытые исходники
- Бесплатность
- Простая установка и конфигурация
- Поддерживает все нужные браузерные движки
- И все три ОС-платформы (MacOS, Windows, Linux)
- Все нужные ЯПы (Python, Java, JS, C#)
- Поддерживает тест-раннеры (Mocha, Jest, Jasmine)
- Сочетает headless-тестирование с event-driven архитектурой
- Интегрируется с инструментами CI/CD (Jenkins, CircleCI, Azure Pipeline, TravisCI)
- Подходит для сложных приложений
- Автоматические ожидания — не надо прописывать эксплицитное ожидание
- Функция auto-wait
- Параллельное выполнение в контекстах, когда много вкладок надо открыть одновременно
- Генерация тестов
- Есть удобный Reporter
- Возможности дебага
Минусы
- Относительно новый продукт
- Не поддерживает IE, что впрочем уже не минус
- Не поддерживает нативные мобильные приложения (но есть же эмуляторы)
- Не очень большое комьюнити
Чем отличается от других популярных фреймворков
Установка
Устанавливаем через npm:
npm init playwright@latest
Далее:
- Указываем TypeScript или JavaScript (по умолчанию TypeScript)
- Даем название папке с тестами, или оставляем дефолтное tests
- (Опционально) добавляем воркфлоу GitHub Actions
- Устанавливаем браузеры (по умолчанию)
Playwright загрузит нужные браузеры и создаст конфигурации:
playwright.config.ts package.json package-lock.json tests/ example.spec.ts tests-examples/ demo-todo-app.spec.ts
В конфиг-файле playwright.config можно потом указать, какие браузеры будут запускаться. Если проект уже есть, зависимости в package.json добавятся автоматически.
В папке tests есть образец теста, который можно попробовать запустить; также папка tests-examples с тестами приложения-планировщика.
Запуск примера
По умолчанию тесты запускаются в браузерах Chromium, Firefox, Webkit. Это можно настроить в конфиг-файле. Запуск в headless-режиме (окна не открываются). Результаты и логи — в терминале.
npx playwright test
HTML-репорты
После выполнения теста создается репорт, который можно посмотреть по браузерам, по статусам pass/fail/skipped, и также по стабильности. По каждому тесту описываются этапы и ошибки. Репорт откроется автоматически если какие-то тесты упали.
npx playwright show-report
Как работает Playwright
В Playwright тесты выполняют действия, и сравнивают состояния с ожидаемыми (assert-функциональность).
Нет необходимости дополнительно прописывать wait-ожидания, так как Playwright автоматически ожидает результаты проверки перед тем как перейти к следующему действию; ожидания неплохо настроены, это позволяет забыть о таймаутах и некорректных ожиданиях, вызывающих нестабильность тестов.
Первый тест
Ниже имеем пример:
import { test, expect } from '@playwright/test';
test('has title', async ({ page }) => {
await page.goto('https://playwright.dev/');
// Expect a title "to contain" a substring.
await expect(page).toHaveTitle(/Playwright/);
});
test('get started link', async ({ page }) => {
await page.goto('https://playwright.dev/');
// Click the get started link.
await page.getByRole('link', { name: 'Get started' }).click();
// Expects the URL to contain intro.
await expect(page).toHaveURL(/.*intro/);
});
Примечание: для JS-тестов в VS Code нужно будет добавить в начало каждого теста: @ts-check (автопроверка типов)
Навигация
Как правило, веб-тесты начинаются с захода на какой-то URL:
await page.goto('https://playwright.dev/');
Playwright ожидает, пока страница не завершит загрузку.
Взаимодействия и локаторы
Взаимодействие с элементом начинается с того что его нужно найти локатором. Playwright ожидает, пока элемент не перейдет в доступное состояние перед выполнением действия, поэтому отдельные wait’ы не нужны.
// Create a locator.
const getStarted = page.getByRole('link', { name: 'Get started' });
// Click it.
await getStarted.click();
Это можно написать одной строчкой:
await page.getByRole('link', { name: 'Get started' }).click();
Базовые действия
| Действие | Описание |
|---|---|
| locator.check() | Проставить чекбокс |
| locator.click() | Клик на элементе |
| locator.uncheck() | Снятие чекбокса |
| locator.hover() | Наведение на элемент |
| locator.fill() | Заполнение формы (быстрое) |
| locator.focus() | Фокус на элементе |
| locator.press() | Нажатие кнопки |
| locator.setInputFiles() | Выбор файлов на передачу |
| locator.selectOption() | Выбор в выпадающем списке |
| locator.type() | Заполнение формы (медленно, по одной букве) |
Assertions
В Playwright тестовые assertions реализованы в форме функции expect. Вызывается expect(value) и указывается соответствующий матчер, например toEqual, toContain, toBeTruthy:
expect(success).toBeTruthy();
Есть также асинхронные матчеры, ожидающие некоего условия. Например, код, ожидающий, когда страница получит имя ‘Playwright’:
await expect(page).toHaveTitle(/Playwright/);
Список assertions в Playwright:
| Assertion | Проверка, что: |
|---|---|
| expect(locator).toBeChecked() | Чекбокс проставлен |
| expect(locator).toBeEnabled() | Элемент включен |
| expect(locator).toBeVisible() | Элемент видимый |
| expect(locator).toContainText() | Элемент содержит текст |
| expect(locator).toHaveAttribute() | У элемента есть такой атрибут |
| expect(locator).toHaveCount() | Список элементов указанной длины |
| expect(locator).toHaveText() | Элемент содержит такой текст |
| expect(locator).toHaveValue() | Элемент имеет такое значение |
| expect(page).toHaveTitle() | Страница имеет такой тайтл |
| expect(page).toHaveURL() | Страница имеет такой URL |
| expect(page).toHaveScreenshot() | Тестраннер делает два скриншота, второй из них сравнивается с образцом |
Изоляция тестов
Базируется на концепции фикстур, передаваемых в тест. Страницы изолируются по контекстам браузера, что эквивалентно новому профилю браузера, то есть каждый тест выполняется в новом окружении (даже если в одном браузере запускается много тестов).
test('basic test', async ({ page }) => {
...
Тестовые хуки
Применяются хуки типа test.describe для объявления группы тестов, и test.beforeEach и test.afterEach для выполнения до/после каждого теста. Есть также хуки test.beforeAll / test.afterAll, срабатывающие до/после всех тестов.
import { test, expect } from "@playwright/test";
test.describe("navigation", () => {
test.beforeEach(async ({ page }) => {
// Go to the starting url before each test.
await page.goto("https://playwright.dev/");
});
test("main navigation", async ({ page }) => {
// Assertions use the expect API.
await expect(page).toHaveURL("https://playwright.dev/");
});
});
Запуск тестов
По одному, группа тестов, или все; в одном или нескольких браузерах. По дефолту тесты запускаются в headless-режиме — окна не открываются, результаты выводятся в терминал.
Есть VS Code Extension, для запуска тестов, вставки брейкпойнтов и отладки в IDE VS Code.
Командная строка
Запуск всех тестов:
npx playwright test
Одного теста:
npx playwright test landing-page.spec.ts
Нескольких тестов:
npx playwright test tests/todo-page/ tests/landing-page/
Если в тестах в имени файла есть landing или login:
npx playwright test landing login
Запуск тестов, содержащих тайтл:
npx playwright test -g "add a todo item"
В headed-режиме:
npx playwright test landing-page.spec.ts --headed
По отдельному проекту:
npx playwright test landing-page.ts --project=chromium
Дебаг
Так как Playwright это Node.js-библиотека, можно выполнять отладку используя console.log, или в IDE, или, что удобнее, в VS Code Extension. В Playwright есть Инспектор, где можно смотреть API-вызовы, логи отладки и локаторы.
Отладка всех тестов:
npx playwright test --debug
Одного теста:
npx playwright test example.spec.ts --debug
Начать отладку со строки, содержащей test( :
npx playwright test example.spec.ts:10 --debug
Репорты
В Playwright есть Reporter для анализа результатов, по времени выполнения теста, и на каких браузерах. Фильтрация по пройденным/упавшим/пропущенным/нестабильным. Вывод отдельно по браузерам;через Поиск можно найти интересующий тест.
Репорты открываются после выполнения тестов:
npx playwright test
Открываются автоматически, если среди тестов есть красные. Чтобы открыть репорты вручную:
npx playwright show-report
Подробный репорт по каждому тесту — клик по имени. Доступна детальная информация по ошибке; также детальный просмотр каждого этапа теста и кода на этом этапе, и времени выполнения.
В проектах, созданных через create-playwright, HTML-репорты открываются автоматически. Если в конфигурации не прописаны HTML-репорты, или если команда show-report не работает, открыть репорт вручную командой: —reporter=html.
npx playwright show-report --reporter=html
Генератор тестов
Playwright умеет генерировать тесты. Откроет два окна: браузера, в котором происходит взаимодействие с контентом страницы, и Инспектора, в котором тесты записываются, копируются, корректируются и т.п.
Запуск Codegen
npx playwright codegen demo.playwright.dev/todomvc
Запускаем Codegen и выполняем нужные действия в браузере. Система будет генерировать код этих действий. В Codegen будут созданы соответствующие селекторы. Как это работает — скриншот ниже; или лучше скачать к себе и посмотреть видео по этой ссылке.
После завершения действий в браузере нажимаем кнопку Record, чтобы остановить запись действий, и копируем, кнопкой Copy, сгенерированный код в редактор.
Трассировка
Есть Trace Viewer для просмотра записанных трассировок; можно вернуться и пошагово проверить действия в тесте, то есть визуально проконтролировать, что происходило на каждом этапе.
Запись трассировки
По умолчанию в конфиг-файле Playwright прописано создание архива trace.zip с трассировкой каждого теста. Трассировки начинаются после первого повторного запуска упавшего теста (значение on-first-retry). При работе в CI количество повторных запусков =2, при локальной работе =0. То есть трассировки будут записываться при первом повторном запуске упавшего теста (а не после первого запуска, и не после второго повторного запуска).
// @ts-check
const { defineConfig } = require('@playwright/test');
module.exports = defineConfig({
retries: process.env.CI ? 2 : 0, // set to 2 when running on CI
...
use: {
trace: 'on-first-retry', // record traces on first retry of each test
},
});
Трассировки чаще запускаются в CI-окружении; в локальном окружении используются обычные методы отладки. При этом, можно пользоваться этой функцией и локально, включив ее командой —trace on
npx playwright test --trace on
Просмотр трассировок
Просмотр действий в таймлайне — что изменилось после какого-то действия. Также лог сетевых событий при каждом действии. Создается снепшот DOM; можно открыть devtools и т.п.
CI GitHub Actions
При установке Playwright есть опция добавить GitHub Actions. При этом создастся файл playwright.yml в папке .github/workflows со всем нужным.
Тесты будут запускаться после push— и pull-реквестов в main/master. Workflow установит все зависимости, установит сам Playwright, и запустит тесты. А также создаст HTML-репорт.
name: Playwright Tests
on:
push:
branches: [main, master]
pull_request:
branches: [main, master]
jobs:
test:
timeout-minutes: 60
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: 18
- name: Install dependencies
run: npm ci
- name: Install Playwright Browsers
run: npx playwright install --with-deps
- name: Run Playwright tests
run: npx playwright test
- uses: actions/upload-artifact@v3
if: always()
with:
name: playwright-report
path: playwright-report/
retention-days: 30
Создание репозитория и push на GitHub
Следует ознакомиться с инструкциями на Гитхабе и не забыть инициализировать репозиторий командой git init. Далее можно использовать стандартные add/commit/push на Гитхабе:
Workflow
Во вкладке Actions на GitHub — статус тестов (passed/failed):
Советы и лучшие практики
Тестировать в первую очередь то, что видит пользователь
Автоматизация тестов должна верифицировать приложение для пользы конечных пользователей, и не слишком углубляться в то, что пользователь никогда не видит и с чем никогда не взаимодействует.
Максимально изолировать тесты друг от друга
Идеальный тест — максимально не зависящий от других тестов, со своим локальным хранилищем, сессиями, данными, кукисами и прочим. Это улучшает воспроизведение багов, не дает возможность возникнуть каскадным багам.
Меньше тестов, и больше сами тесты
Так как дело касается e2e-тестов, то большие тесты это не так плохо. Даже если в них будет очень много действий и assertions. Лучше не «разносить» assertions по отдельным тестам, это замедлит выполнение и принесет мало пользы.
Избегать third-party-зависимостей
Тестировать только то что можно проконтролировать; не ссылки на внешние сайты/серверы. Это, во первых, заберет время, а также будут проблемы с контентом/кукисами и прочим.
Полезные функции локаторов
Пользоваться полезными функциями локаторов: auto-waiting и retry, а также фильтрацией локаторов и их последовательностями:
const product = page.getByRole('listitem').filter({ hasText: 'Product 2' });
Лучше применять локаторы, устойчивые к изменениям в DOM:
? page.getByRole('button', { name: 'submit' })
Генерировать локаторы в Codegen
Генератор тестов (Codegen) подбирает нужные локаторы, по их релевантности, тексту, и ID.
Генерировать локаторы в VS Code Extension
Миграция с Puppeteer
В целом не очень сложная. Синтаксис похож (с небольшими различиями например при запуске браузера).
| Puppeteer | Playwright |
|---|---|
| await puppeteer.launch() | await playwright.chromium.launch() |
| puppeteer.launch({product: ‘firefox’}) | await playwright.firefox.launch() |
| WebKit не поддерживается в Puppeteer | await playwright.webkit.launch() |
| await browser.createIncognitoBrowserContext(…) | await browser.newContext(…) |
| await page.setViewport(…) | await page.setViewportSize(…) |
| await page.waitForXPath(XPathSelector) | await page.waitForSelector(XPathSelector) |
| await page.waitForNetworkIdle(…) | await page.waitForLoadState({ state: ‘networkidle’ } |
| await page.$eval(…) | Для верификации текста/атрибута/класса применяются Assertions |
| await page.$(…) | Нежелательно, лучше использовать Locators |
| await page.$x(xpath_selector) | Нежелательно, лучше использовать Locators |
| Нет методов по чекбоксу или радиокнопке | await page.locator(selector).check() await page.locator(selector).uncheck() |
| await page.click(selector) | await page.locator(selector).click() |
| await page.focus(selector) | await page.locator(selector).focus() |
| await page.hover(selector) | await page.locator(selector).hover() |
| await page.select(selector, values) | await page.locator(selector).selectOption(values) |
| await page.tap(selector) | await page.locator(selector).tap() |
| await page.type(selector, …) | await page.locator(selector).type(…) Также можно locator.fill(value[, options]) |
| await page.waitForFileChooser(…) await elementHandle.uploadFile(…) | await page.locator(selector).setInputFiles(…) |
| await page.cookies([…urls]) | await browserContext.cookies([urls]) |
| await page.deleteCookie(…cookies) | await browserContext.clearCookies() |
| await page.setCookie(…cookies) | await browserContext.addCookies(cookies) |
| page.on(…) | page.on(…)для перехвата и изменения запросов, см. page.route(url, handler[, options]) |
page.waitForNavigation и page.waitForSelector те же. Однако, эти функции уже применяются реже, поскольку Playwright обновлён функцией auto-waiting. Вместо прописывания условий и времени ожидания Playwright автоматически ожидает доступности нужных UI-элементов, и только тогда выполняет действие.
Playwright: FAQ
Для тех кто не любит тратить время на видео. Вопросы и ответы на вебинаре (актуально для 2022 г). Вопросы разбиты по категориям. Отвечал Андрей Лушников из Microsoft, один из создателей Playwright.
Вопросы по функциональности
Способен ли Playwright определять проблемы с отзывчивостью интерфейса? Например с выпадающими списками при наведении мышкой.
- Можно измерить время вызова. В Playwright Trace можно сериализовать и отрабатывать это.
- В Chromium трейсинг. Можно бросить этот файл в devtools и посмотреть производительность. Ссылка.
- Также тайминги по ресурсам: ссылка.
- Работает в Java, Python и JS.
Поддерживаются ли моки типа cy.intercept? Можно ли получить репорт по покрытию в Playwright? Есть ли что-то подобное cy.wait()? Можно ли запускать webkit-тест в контейнере как часть пайплайна?
Да. Подробнее здесь.
Дает ли Playwright доступ к окнам отображаемым браузером, не только страницами? (типа окна загрузки)
Да, об этом здесь. Есть API для приема/отказа/обработки загрузок. Можно отрабатывать диалог передачи/загрузки файла, а также вставлять файлы в input-элементы.
Когда страница открывается через контекст браузера, она рендерится с GUI или в headless-режиме?
С точки зрения рендеринга нет разницы между headless- и headful-режимами.
Playwright поддерживает Salesforce iFrames?
Да, поддерживает в браузерах на основе Chromium, подробнее здесь.
Какое стандартное время ожидания загрузки элемента в Playwright?
По дефолту 30 секунд. Таймаут может быть прописан локально или глобально. Подробнее здесь.
Может ли Playwright находить элементы по ID?
Да. Подробнее о селекторах.
Можно ли запускать тесты параллельно?
Да, тест-раннеры типа pytest и Jest умеют запускать Playwright-тесты параллельно.
Можно ли отображать курсор при записи видео?
Пока нет. Если очень хотите, сделайте соответствующий реквест на GitHub.
Являются ли assertions нативными в Playwright? Или берутся в Jest?
В большинстве примеров взята expect-библиотека из Jest, но это на ваше усмотрение.
Как имплементируются Data-Driven-методы? Как скрипт получает внешние данные? Как проводятся множественные итерации с наборами данных?
Это больше касается тест-раннера. В разных тест-раннерах есть свои API для этого.
Есть ли в Playwright функция для работы с canvas?
Нет, ничего такого. Можно кликнуть в рендомном месте и вручную что-то ввести, но ничего специального по canvas.
Действия, если нужно кликнуть отключенную (disabled) кнопку? Какая в Playwright wait-стратегия — есть ли таймаут?
Будет ждать таймаута — подробнее.
Как запустить набор тест-кейсов с разными файлами?
Это зависит от тест-раннера: jest-playwright, cucumber и пр.
Элемент должен быть в видимой области (вьюпорте), чтобы иметь активный статус?
Нужно промотать до места элемента. И убедиться, что он не заслонен чем-то.
Делается ли детальное протоколирование (verbose logging) того что делал Playwright перед тем как тест упал?
Да. О verbose-логах здесь.
Как выводятся ошибки при падении теста?
В форме эксепшенов, с детальными логами действий.
Есть ли какая-то поддержка мультитрединга?
Нет, ничего такого. Тест-раннер делит тестовые процессы.
Как работает Auto-Waiting? Если кнопка активирована после запроса, нужно ли это постоянно проверять? Каждые ‘x’ секунд, и таймаут каждые ‘y’ секунд?
Да, примерно так.
Есть метод waitForNavigate, как он имплементируется?
Проще говоря, waitForNavigation ожидает любое действие навигации.
А зачем нужен waitForNavigation, если есть механизм auto-wait?
Для случаев, когда нужно именно ожидание действия навигации. Например заполняется большая форма на нескольких страницах, на каждой страница кнопка «Далее». Если нужно кликнуть «Далее» на первых двух страницах, можно применить waitForNavigation после первого клика и перед вторым, чтобы не кликать два раза первую кнопку.
Что насчет автоматизации анимированных элементов, типа WebGL? Поддерживаются?
WebGL это просто canvas-элемент, поэтому с ним работаем через мышу и скрипт на JS. Нет специальной поддержки WebGL.
Планируется ли поддержка компонентного тестирования в Playwright?
Пока не знаем, но можете сделать запрос.
Чем отличается параллельный запуск тестов в Playwright и Cypress?
Это больше зависит от тест-раннера, а не от Cypress или Playwright.
Годится ли Playwright для тестирования API?
Некоторые компании тестируют API и производительность, там где им нужно протестировать паттерны реальных пользователей, но лучше все-таки специализированные инструменты для тестирования API.
Как Playwright обрабатывает (обходит) ошибку SSL-сертификата?
Ставим настройку «Игнорировать все ошибки HTTPS», подробнее здесь.
Как Playwright определяет, что страница уже загрузилась?
Playwright не определяет это в явном виде, но это и не особо нужно. Вместо этого ждем когда нужный элемент будет доступен, например кнопка page.click(‘text=Submit’), так проще.
Есть ли ожидание, перехват и парсинг HTTP-запросов (например API), когда страница загружена или изменена в фоновом режиме?
Да. Здесь подробно.
Работает ли Playwright асинхронно по умолчанию? То есть нужно ли прописывать async/await эксплицитно?
Это зависит от языка.
Как работать с Playwright Inspector в Visual Studio Code?
Нужно выбрать или то, или другое, зависит от ситуации.
Есть ли аналог cy.click({force:true}) в Playwright? Она интегрирована в Auto Wait?
Да, такое есть, это page.click({ force: true }). Подробнее.
Иногда нужно ждать полной загрузки страницы, чтобы сделать скриншот. В одностраничном приложении (SPA) функции waitForNavigation и waitForLoadState могут работать не идеально. Остается waitForSelector?
Да, точно. Только визуальный критерий.
Вопросы по интеграции
Как Playwright работает с Continuous Integration?
Этому посвящен подробный раздел в документации.
Как с Playwright интегрируются тестовые библиотеки типа JUnit и TestNG?
Отлично интегрируются, и большинство клиентов так делают.
Есть ли возможность интеграции с инструментом параллельного тестирования zalenium?
Нет, это не очень распространенный инструмент.
Есть ли интеграция с Cucumber?
Частичная — E2E Cucumber+Playwright.
Есть ли интеграция с TestRail?
Да, можно почитать об этом здесь.
Есть ли GitHub Action для запуска в облаке?
Да.
Assertions в Playwright являются уникальными, или зависят от assertion-библиотеки типа Chai?
В чистом виде нет, но для этого предназначена аналогичная Playwright-функция Expect [прим. — описано в туториале], или Chai.
Вопросы по миграции
Мы пользуемся стеком Jest-Puppeteer-Cucumber (TypeScript). Есть ли инструмент легкой миграции на Playwright?
Нет, но API для базовых операций практически тот же. Скорее всего нужно будет просто удалить несколько waitForSelectors и все будет работать.
Нужно ли будет переделывать наш фреймворк на основе Selenium WebDriver?
Если у вас современный CI/CD, Playwright будет работать «из коробки», используя например GitHub Actions. Но если у вас локальный Selenium grid, нужно будет расширить ваш фреймворк, чтобы Playwright мог работать с вашей фермой браузеров. Затем можно постепенно мигрировать.
Вопросы по платформам
Планируется ли поддержка мобильных приложений? Нативных, гибридных?
Есть поддержка Android в экспериментальном режиме, браузеров и WebView. По iOS ничего нет, но можно поддержать идею на GitHub.
Есть ли что-то подобное Selenium Grid, опенсорсное, работающее с Playwright? Если нет, то планируется?
Наши API дают доступ к функциональности Playwright сторонним приложениям типа Selenium Grid, пока этого достаточно.
Как Playwright работает с браузером? Через HTTP-запросы?
Playwright работает через протокол удаленной отладки (типа CDP в Chromium).
Поддерживается ли Safari?
Да, Safari основан на WebKit, одном из 3 движков которые поддерживаются.
Есть ли ограничения по версиям браузеров?
Поддерживаются последние версии браузеров: стабильные, и беты Chromium и Firefox, а также Safari Technology Preview. Подробнее.
Как насчет старых версий браузеров Chrome, IE и пр.?
Google и Microsoft стараются ограничивать загрузки старых браузеров и заставляют обновлять их. Чтобы поработать со старыми версиями, нужна старая версия Playwright.
Почему Chrome запускается в инкогнито-режиме?
Для изоляции контекста браузера.
Стоит ли у вас цель сделать all-in-one-фреймворк для веб, мобайла и десктопа? И что насчет облачного тестирования?
На данный момент фокусируемся только на вебе. Но есть экспериментальные Android и Electron.
Вопросы по доступности
Playwright с открытым кодом или платный?
С открытым кодом, бесплатный.
Playwright поддерживает Node.js и JavaScript?
Поддерживает JavaScript, TypeScript, Java, Python, Python asyncIO, и C# (альфа). Подробнее.
Умеет ли генератор кода в Playwright писать код на ES6 JS?
Только ES5, но со временем будет ES6.
Генератор поддерживает TypeScript?
Генерируемый ES5-код является валидным TypeScript-кодом. Нет методов в сгенерированных сниппетах.
Playwright поддерживает JavaScript?
Да, с самого начала.
Поддерживаются множество языков, но какой рекомендуете?
Тот, который удобен вам. Скорее всего это JavaScript )
У нас стек состоит из Cypress, TestCafe, Jest/Puppeteer, Playwright и других. На чем остановиться?
Обратите внимание на Playwright API здесь, на множество браузеров которые поддерживаются в Playwright, и тестовое покрытие которое дает Playwright.
Будет ли поддерживаться язык Dart?
Поддержите реквест на GitHub. Если будет много звезд, то да.
Как конвертировать сниппеты кода? Например из JS в Python и наоборот.
Нет, такое не поддерживается, мы только генерируем, но не конвертируем.
Мой вопрос о создании фреймворка автоматизации на Java, корпоративного уровня. Как будет развиваться Java Playwright? Будут ли сниматься ограничения по применению Selenium в JS-приложениях.
Вообще, Playwright намного мощнее, чем WebDriver-решения, и наша Java-версия вполне на уровне. Планируем постепенно убирать ограничения.
Если API имплементированы на C#/Java, будет ли ОК использовать JavaScript в тестах Playwright? Или лучше все-таки на C#/Java.
Никак не зависит. Многие пишут автотесты на JavaScript и Python для тестирования программ на Java/C#.
Что лучше для Playwright? Jest или Folio?
Связка Jest-Playwright отличная, но Folio кажется лучше. [Примечание от 2023: проект Folio объединен с Playwright Test.]
Релизы Playwright синхронизируются с WebKit, обновлениями Chrome, WebDriver?
Playwright релизится ежемесячно.
Вопросы по другим фреймворкам
Чем Playwright отличается от TestCafe?
Сильно отличается, и в лучшую сторону. Playwright умеет делать например вот такое.
Все вокруг говорят о no-code-автоматизации. Что по Playwright?
Мы рассматриваем Playwright как фундаментальный продукт. Его API стоит на script-based-тестировании, но теоретически можно делать намного больше, по крайней мере что касается кроссбраузерного тестирования. Возможно, в будущем появятся no-code-решения на «фундаменте» Playwright.
Чем, по большому счету, Playwright отличается от Cypress?
Playwright поддерживает все браузерные движки, в нем больше функций чем в Cypress (сеть, прокси, мобайл, эмуляция), и Playwright работает с браузером напрямую. И у нас традиционная модель программирования (а не цепочка из API).
Вопросы по дизайну
Используется ли что-то подобное Page Object Model? Чтобы избегать hard-coded значений для объектов.
Сценарий Playwright является программой, и ведет себя как программа, включая параметры, переменные и пр.
Какие рекомендуете паттерны дизайна автотестов в Playwright (как Page Object Model в Selenium).
Page Object Model прекрасно работает и в Playwright, как и другие дизайн-паттерны. Пример.
С точки зрения архитектуры Playwright, нормально ли применять Page Object Model или Screenplay?
Playwright является библиотекой, поэтому можно применять любые программы и паттерны «поверх» Playwright.
Как имплементировать POM на JavaScript, и как генерировать исполняемый файл?
В Node.js не генерируется исполняемый файл, а пишется программа и выполняется при помощи ‘node script.js’. Не обязательно применять Node.js если это не любимый язык, Playwright работает и с Java, и с Python.
Вопросы по комьюнити и поддержке
Подскажите хорошее комьюнити по Playwright.
Slack-канал, например.
Есть ли ресурсы по Playwright Java?
Slack-канал, и выбрать канал -java. Проблемы — на GitHub.
Кому принадлежат права на Playwright? Microsoft? Будет ли продукт поддерживаться в будущем?
Да, разработан в департаменте Microsoft Developer Vision. Там же создавались Visual Studio, Visual Studio Code, .NET и Azure. Будет поддерживаться, это одно из ключевых направлений.
Источник FAQ
***
