Playwright позволяет управлять браузерами и проверять web-приложения. В экосистеме JavaScript и TypeScript Playwright Test добавляет runner, fixtures, assertions, проекты и отчёты. Для QA важны не только удобные команды, но и возможность изолировать состояние и сохранять подробную историю отказа.
Инструмент подходит для пользовательских цепочек, проверки интерфейсных состояний и части API-задач. При этом автоматическое ожидание не заменяет понимание приложения: доступная кнопка ещё не означает завершённый бизнес-процесс, а успешный HTTP-ответ ещё не означает правильные данные.
Установка и воспроизводимость
Для нового учебного проекта можно использовать npm init playwright@latest. Выберите JavaScript или TypeScript и установку браузеров. Требуется версия Node, поддерживаемая выбранным релизом. В рабочем репозитории сохраняйте package-lock.json и устанавливайте зависимости через npm ci.
Версии браузерных сборок связаны с установленным Playwright. После обновления пакета обновляют соответствующие браузеры и проверяют системные зависимости CI. Использование случайного глобального executable может добавить различия между локальной машиной и агентом, поэтому такой выбор фиксируют явно.
Локаторы и доступные имена
Playwright поддерживает локаторы по роли, label, тексту и test id. Локатор описывает способ найти элемент в актуальном состоянии страницы. Это удобнее хранения старой ссылки на DOM-узел, который приложение может заменить при перерисовке.
Выбирайте признак по смыслу. Для формы getByLabel связывает тест с доступной подписью, для кнопки getByRole с именем выражает пользовательское действие. Если совпадений несколько, уточните контейнер. Автоматический выбор первого элемента способен скрыть неоднозначность и нажать чужую кнопку.
Самостоятельный пример
В созданном проекте сохраните tests/profile.spec.js. Пример использует страницу в памяти и не требует сервера. Выполните npx playwright test tests/profile.spec.js. Учебное правило: пустое имя отклоняется, непустое приводит к сообщению об успехе; реального сохранения здесь нет.
const { test, expect } = require('@playwright/test');
test('валидирует имя после отправки', async ({ page }) => {
await page.setContent(`
<label>Имя <input id="name"></label>
<button id="save">Сохранить</button><p role="status"></p>
<script>
document.querySelector('#save').onclick = () => {
const name = document.querySelector('#name').value.trim();
setTimeout(() => {
document.querySelector('[role=status]').textContent =
name ? 'Сохранено' : 'Введите имя';
}, 100);
};
</script>`);
await page.getByRole('button', { name: 'Сохранить' }).click();
await expect(page.getByRole('status')).toHaveText('Введите имя');
await page.getByLabel('Имя').fill('Анна');
await page.getByRole('button', { name: 'Сохранить' }).click();
await expect(page.getByRole('status')).toHaveText('Сохранено');
});Ожидаются ошибка пустого значения и затем успех допустимого значения. toHaveText повторяет наблюдение до выполнения условия или таймаута. await обязателен для асинхронных действий и assertions: пропуск может дать неправильный порядок и незавершённую проверку.
Что именно ждёт инструмент
Перед действием Playwright проверяет необходимые условия вроде видимости и доступности взаимодействия, в зависимости от операции. Это не означает, что он знает о завершении фонового расчёта, доставки письма или обработки очереди. Такие результаты требуют отдельного наблюдаемого условия.
Предпочитайте web-first assertions для динамического UI. Получить текст сразу и сравнить обычным assert — значит проверить единственный момент времени. Но не заменяйте любое ожидание огромным timeout: если событие не должно происходить, длительное ожидание не исправит сценарий.
Практический переход к реальному профилю
Создайте отдельного тестового пользователя, откройте его кабинет и отправьте имя из пробелов. Ожидайте ошибку и прежнее сохранённое значение. Во втором сценарии отправьте новое допустимое имя, затем перечитайте профиль через UI или API в соответствии с целью проверки.
Если тест использует network mocking, он подтверждает обработку заданного ответа клиентом. Для настоящего сохранения оставьте отдельную интеграционную проверку без подмены этой операции. Граница между контролируемой ошибкой интерфейса и реальной связью с backend должна быть видна в названии набора.
Fixtures и независимость
Playwright Test создаёт изолированное браузерное состояние для тестов через контексты. Это помогает с cookie и storage, но не изолирует серверные записи автоматически. Два контекста под одним аккаунтом всё ещё могут менять один профиль или одну корзину.
Fixtures подходят для подготовки пользователя, клиента API и нужных сущностей. Область жизни fixture выбирают осознанно. Общий ресурс уровня worker должен быть безопасен для всех тестов этого worker; изменяемые данные конкретного сценария лучше создавать отдельно.
Проекты и браузерная матрица
Projects позволяют описать разные конфигурации: браузер, viewport, локаль и другие параметры. Запускайте матрицу по риску, а не все возможные комбинации автоматически. Сначала подтвердите критическую цепочку, затем добавьте области, чувствительные к выбранному окружению.
Эмуляция мобильного устройства не заменяет реальный телефон с его клавиатурой, разрешениями и системными интеграциями. Автоматизированный WebKit также не следует объявлять полной проверкой пользовательского Safari. Ограничения покрытия полезно фиксировать рядом с результатами.
Trace и расследование
Trace Viewer помогает изучать действия и состояние страницы вокруг отказа. Сохраняйте trace по выбранной политике, например при повторной попытке или ошибке, и обеспечьте доступ к нему из CI. Перед публикацией учитывайте, какие данные попали в сетевые записи и скриншоты.
Начинайте расследование с первого нарушенного ожидания: какой запрос ушёл, что пришло и что показал UI. Не переписывайте локатор вслепую, если причина в недоступном backend. Повторный зелёный запуск полезен как наблюдение, но исходное падение требует классификации.
При многопользовательском сценарии создайте два отдельных контекста и подпишите роль каждого участника в отчёте. Сохранение файла storage state для ускорения входа не должно объединять аккаунты или раскрывать их сессионные данные в общедоступном артефакте. Убедитесь, что состояние соответствует нужному окружению и ещё валидно. Если подготовка авторизации сломалась, отметьте именно этот этап: десятки последующих ошибок поиска элементов личного кабинета не являются независимыми дефектами интерфейса.
Ошибки и рабочие выводы
Типичные проблемы: забытый await, общий изменяемый аккаунт, force click без расследования и проверка только появления сообщения. Сгенерированный тест нужно редактировать: генератор помогает начать, но не выбирает за команду риск, данные и критерий успеха.
Надёжный Playwright-набор сочетает изоляцию, понятные локаторы, явный бизнес-результат и полезные артефакты. Быстрый старт инструмента ценен тогда, когда команда столь же осознанно управляет серверным состоянием и границами покрытия.
Что ещё почитать
- →Playwright: Installation
- →Playwright: Auto-waiting
- →Playwright: Test fixtures
- →Playwright: Trace viewer
Воспроизводимое локальное упражнение
Подготовленный учебный проект фиксирует @playwright/test 1.59.1 и lockfile, а сервер запускает локальная Python-фикстура. Семь Chromium-кейсов проверяют пустой, короткий, граничный, слишком длинный ввод, пробел и Unicode. Каждый кейс получает свою страницу и явное ожидание. Внешние аккаунты и production-сайты не используются.
npm ci
npx playwright install chromium
npm test
# Если тест завершился ошибкой и сохранил trace:
npx playwright show-trace test-results/<case-directory>/trace.zipКонфигурация запускает локальный сервер и сохраняет trace при ошибке. Локаторы используют label поля и роль кнопки, чтобы выражать действие пользователя. Assertions повторяют проверку до выполнения условия или таймаута; произвольные sleep для этой синхронной формы не нужны.
await page.goto("/demo.html");
await page.getByLabel("Nickname").fill("ab");
await page.getByRole("button", { name: "Validate" }).click();
await expect(page.getByRole("alert")).toHaveText("Use 3–12 ASCII letters.");
await expect(page.getByLabel("Nickname")).toBeFocused();Для учебной ошибки измените ожидаемый текст сообщения в одном локальном тесте, выполните только его, изучите сохранённый trace и верните assertion. Успех доказывает соответствие этой фикстуры этим проверкам, а не полную доступность или достаточное тестирование реального продукта. При адаптации добавьте настоящий процесс и проверки бэкенда.