Playwright: автотесты в браузере для новичка

ИИ может за несколько минут добавить в игру меню, звук или таблицу рекордов. Но высокая скорость правок создаёт новую проблему: после очередного изменения кнопка «Старт» внезапно перестаёт работать, счёт не обновляется, а рекорд исчезает после перезагрузки. Playwright помогает поручить браузеру повторяемую проверку таких сценариев и сразу увидеть, где приложение сломалось.

Что такое Playwright простыми словами

Playwright — инструмент для автоматического управления браузером и проверки веб-приложений. Он запускает браузер, открывает нужный адрес, нажимает кнопки, вводит текст и сравнивает результат с тем, который ты ожидаешь. По сути, это робот-тестировщик: он выполняет заранее записанный сценарий так, как сделал бы обычный пользователь.

Допустим, у тебя есть браузерная «Змейка». При ручной проверке ты открываешь страницу, нажимаешь «Старт», смотришь, появилась ли игровая область, двигается ли змейка и начинается ли счёт с нуля. В Playwright те же действия записываются как код. После этого сценарий можно запускать сколько угодно раз — после изменения цветов, добавления магазина или переноса рекордов в базу данных.

Слово playwright часто встречается рядом с выражением end-to-end, сокращённо E2E. Это значит «от начала до конца». Такой тест проходит через несколько частей приложения сразу: страницу, JavaScript, хранилище, а иногда сервер и базу данных. Он не спрашивает, правильно ли работает одна отдельная функция. Он проверяет видимый итог: может ли человек выполнить нужное действие.

Playwright умеет работать с распространёнными браузерными движками. Браузерный движок — часть браузера, которая читает HTML, CSS и JavaScript и рисует страницу. Благодаря этому один сценарий можно прогонять в нескольких браузерных средах, если проекту действительно нужна такая проверка. Для первого проекта разумнее начать с одного основного браузера, добиться стабильности и только потом расширять набор.

Обычный поток проверки выглядит так:

flowchart TB
    test["Тест"] --> browser["Запуск браузера"]
    browser --> actions["Действия на странице"]
    actions --> checks["Проверка ожиданий"]
    checks --> report["Отчёт"]
    report --> success["Успех"]
    report --> failure["Падение со скриншотом"]

Playwright не оценивает, красиво ли выглядит дизайн и удобно ли играть. Он проверяет только то, что сформулировано в сценарии. Если тест проверяет наличие канваса и нулевой счёт, он не заметит, что текст обрезан или кнопка слишком мала. Поэтому автоматическая проверка дополняет просмотр страницы человеком, а не отменяет его.

Чем Playwright отличается от юнит-тестов

Юнит-тест проверяет маленькую часть программы отдельно от остального приложения. Такой частью, или «юнитом», может быть функция подсчёта очков. Ей передают исходное значение и проверяют, вернула ли она правильное новое значение. Браузер для этого обычно не нужен, поэтому юнит-тесты выполняются быстро.

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

Эти виды проверок не конкурируют. Удобная стратегия похожа на пирамиду: много быстрых проверок логики, меньше браузерных тестов для самых ценных путей. Подробное объяснение уровней и терминов есть в материале «Автотесты для новичков».

Для «Змейки» разделение может быть таким:

• юнит-тест проверяет, что за съеденную еду начисляется нужное количество очков;
• юнит-тест проверяет столкновение головы змейки со стеной;
• Playwright проверяет, что кнопка запускает игру и показывает канвас;
• Playwright проверяет, что видимый счёт растёт во время успешного сценария;
• Playwright проверяет, что рекорд остаётся после перезагрузки страницы.

Если писать только браузерные тесты, набор станет медленным и сложным в обслуживании. Если писать только юнит-тесты, можно пропустить разрыв между правильными деталями: функция работает, но интерфейс её не вызывает. Новичку достаточно понимать эту границу и просить Claude Code выбирать самый простой уровень, который способен поймать нужную поломку.

Зачем Playwright новичку, чей код пишет ИИ

Когда код пишет Claude Code, ты быстрее переходишь от идеи к результату, но не просматриваешь каждую строку как опытный разработчик. Даже аккуратная правка может задеть соседнее поведение. ИИ способен переименовать элемент, перенести обработчик клика, изменить структуру HTML или заменить способ хранения данных. Страница при этом может открываться без явной ошибки, хотя один из важных сценариев уже не работает.

Тест превращает твоё ожидание в проверяемое правило. Фраза «после нажатия кнопки игра должна запуститься» понятна человеку, но остаётся пожеланием. Сценарий Playwright делает её договором: открыть страницу, нажать кнопку, дождаться игрового состояния и проверить результат. Если новая правка нарушит договор, команда завершится ошибкой.

Для учебной «Змейки» полезны три защитных сценария.

Игра всё ещё запускается

Тест открывает главную страницу, нажимает «Старт» и проверяет, что игровая область видима. Такой сценарий ловит пропавшую кнопку, ошибку JavaScript при запуске, неверный селектор и ситуацию, когда поверх игры случайно остался экран меню.

Счёт действительно растёт

Проверить рост счёта сложнее, чем наличие текста 0: нужно управляемо создать игровое событие. Попроси ИИ добавить тестовый способ разместить еду перед змейкой или установить предсказуемое состояние игры. Не стоит заставлять тест ждать случайного удачного движения. Случайность делает результат ненадёжным.

Таблица рекордов сохраняется

Тест получает результат, перезагружает страницу и проверяет, что запись осталась. Если рекорд хранится в localStorage, Playwright может работать с той же страницей в рамках одного браузерного контекста. Если данные ушли в облачную базу, тесту понадобится отдельная тестовая учётная запись или изолированный набор данных. Боевые записи пользователей для такой проверки использовать не нужно.

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

Ещё один плюс — предметный разговор с ИИ. Вместо «кажется, после твоей правки что-то сломалось» ты передаёшь Claude Code название упавшего теста, сообщение об ошибке и скриншот. У него появляется конкретное наблюдение, а не просьба гадать по всему проекту.

Установка Playwright в проект

Playwright для проекта на JavaScript или TypeScript обычно устанавливают через npm — менеджер пакетов, который приходит вместе с Node.js. Перед началом убедись, что проект уже открывается локально и в его папке есть package.json. Если файла нет, сначала попроси Claude Code проверить структуру проекта, чтобы не создать второй проект внутри первого.

Основная команда установки выглядит так:

npm init playwright@latest

Запускай её в корневой папке проекта — там, где лежит package.json. Установщик задаёт несколько общих вопросов: какой язык использовать для тестов, где хранить файлы и нужен ли пример автоматического запуска. Формулировки и набор вопросов могут меняться, поэтому нет смысла запоминать точные пункты интерфейса. Для курса удобно выбрать TypeScript: он помогает замечать часть ошибок ещё до запуска, а Claude Code уверенно работает с таким кодом.

После установки в проекте обычно появляются или меняются такие элементы:

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

npx playwright install

На сервере CI браузеру могут понадобиться системные библиотеки. Для такой среды есть вариант установки с зависимостями операционной системы:

npx playwright install --with-deps

Не запускай эту команду наугад на рабочем сервере: установка системных компонентов может требовать дополнительных прав. Попроси ИИ сначала определить операционную систему и изучить официальный способ для выбранного CI. Точные версии пакетов также не стоит копировать из случайного старого примера — совместимые актуальные версии должен зафиксировать сам проект.

Что настроить в конфиге

Для локальной «Змейки» особенно полезен baseURL — базовый адрес приложения. Тогда в тесте можно писать page.goto('/'), а не повторять полный адрес. Ещё Playwright способен сам запустить локальный сервер перед тестами через настройку webServer. Это удобнее, чем каждый раз держать отдельное окно терминала.

Попроси Claude Code проверить три вещи:

1. Какая команда действительно запускает проект.
2. На каком локальном адресе приложение становится доступно.
3. Совпадает ли этот адрес с baseURL в конфиге.

Если проект открывается как статические файлы, ИИ может подобрать простой локальный сервер. Открывать HTML через адрес, начинающийся с file://, обычно хуже: поведение модулей, запросов и хранилища отличается от нормальной публикации по HTTP.

Что не добавлять в Git

Код тестов и конфиг обычно сохраняют в репозитории. Тяжёлые загруженные браузеры, временные результаты прогонов и локальные отчёты обычно не хранят в Git. Установщик часто добавляет подходящие правила игнорирования, но попроси ИИ проверить .gitignore, не стирая уже существующие строки.

Первый тест Playwright на «Змейке»

Начни с короткого сценария, который не зависит от случайного появления еды или скорости движения. Его цель: доказать, что страница открылась, кнопка «Старт» сработала, канвас появился, а видимый счёт равен нулю.

До написания кода договорись, как тест найдёт элементы. Локатор — это способ указать Playwright, по какому элементу кликнуть или какой текст проверить. Для важных элементов удобно добавить стабильные атрибуты:

<button data-testid="start-button">Старт</button>
<span data-testid="score">0</span>
<canvas data-testid="game-canvas"></canvas>

Сам тест на TypeScript может выглядеть так:

import { test, expect } from '@playwright/test';

test('игра запускается с нулевым счётом', async ({ page }) => {
  await page.goto('/');
  await page.click('[data-testid="start-button"]');

  await expect(page.locator('[data-testid="game-canvas"]')).toBeVisible();
  await expect(page.locator('[data-testid="score"]')).toHaveText('0');
});

Разберём строки без предположения, что ты уже знаешь программирование.

• test(...) создаёт один именованный сценарий. Название должно объяснять ожидаемое поведение, а не техническую реализацию.
• async и await позволяют дождаться завершения действий браузера. Без ожидания проверка могла бы начаться раньше загрузки страницы.
• page.goto('/') открывает корень сайта. Полный адрес берётся из baseURL в конфиге.
• page.click(...) находит кнопку по data-testid и нажимает её.
• expect(...) формулирует ожидание: канвас должен стать видимым, а счёт — содержать текст 0.

У Playwright есть встроенные ожидания. Команда toBeVisible() не проверяет элемент единственный раз в случайную долю секунды. Она некоторое время повторяет проверку, пока элемент не появится или не истечёт допустимое время. Поэтому обычно не нужно вставлять искусственные паузы после каждого клика.

Если в твоей игре другие элементы

Не копируй пример буквально. В проекте может не быть кнопки с текстом «Старт», отдельного элемента счёта или атрибутов data-testid. Дай Claude Code исходный сценарий и попроси сначала изучить настоящий HTML. Если канвас присутствует ещё до запуска, проверка одной видимости ничего не докажет. Тогда лучше проверять состояние: например, меню скрыто, у игры появился признак running, а обработка клавиш стала активной.

Тест должен подтверждать поведение, а не подгоняться под заранее желаемую зелёную отметку. Плохая практика — попросить ИИ «починить тест любым способом». Он может ослабить ожидание так, что проверка перестанет ловить ошибку. Проси сохранить смысл сценария и отдельно показать, что изменилось в приложении, а что — в тесте.

Как проверить, что тест действительно полезен

Сделай контролируемый эксперимент: временно измени ожидание на заведомо неверное, например потребуй счёт 999, и запусти тест. Он должен упасть с понятным сообщением. Затем верни правильное значение. Это называется отрицательной проверкой самого теста: ты убеждаешься, что зелёный результат появился не потому, что нужная строка вообще не выполнялась.

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

Запуск Playwright CLI и отчёт о тестах

CLI — командный интерфейс. Вместо нажатий в отдельной программе ты вводишь команду в терминале из корня проекта. Основной запуск всех тестов:

npx playwright test

Playwright найдёт тестовые файлы по настройкам проекта, запустит нужный браузер и напечатает результат. Успешный прогон означает только то, что записанные ожидания выполнились. Он не доказывает отсутствие любых ошибок в приложении.

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

npx playwright test --headed

Окно может открыться и закрыться быстро. Для спокойного пошагового разбора удобен режим интерфейса Playwright:

npx playwright test --ui

Назначение команд стабильнее конкретного вида интерфейса, который меняется между выпусками. Если расположение кнопок отличается от чужого скриншота, попроси Claude Code посмотреть доступные команды через справку установленной версии:

npx playwright test --help

Как запустить один сценарий

Во время исправления ошибки нет смысла каждый раз прогонять весь набор. Можно указать конкретный файл:

npx playwright test tests/snake-start.spec.ts

Ещё можно отфильтровать тесты по части названия:

npx playwright test -g "игра запускается"

После исправления всё равно запусти полный набор. Один зелёный сценарий не гарантирует, что правка не задела соседние функции.

Что показывает HTML-отчёт

HTML-отчёт собирает результаты в страницу: какие сценарии прошли, какие упали, сколько заняли действия и где возникла ошибка. Открыть уже созданный отчёт обычно можно командой:

npx playwright show-report

При падении особенно полезны три артефакта:

• сообщение о несовпавшем ожидании;
• скриншот страницы в момент ошибки;
• трассировка, если она включена, — запись ключевых шагов, состояния страницы и сетевых событий.

Скриншот при падении настраивается в playwright.config.ts. Попроси Claude Code включить его только для ошибок, чтобы папка результатов не росла после каждого успешного прогона. Трассировку тоже разумно сохранять для неуспешных или повторных запусков, а не всегда.

Отчёты и скриншоты отвечают на разные вопросы. Строка ошибки сообщает: «ожидался счёт 0, получен пустой текст». Скриншот показывает, не перекрыла ли страницу заставка. Трассировка помогает увидеть последовательность действий. Передавай ИИ все доступные данные вместе — так меньше риск, что он исправит не ту причину.

Playwright MCP: как Claude Code управляет браузером

MCP расшифровывается как Model Context Protocol. Это способ подключить к ИИ-агенту внешний инструмент через сервер с понятным набором команд. Общий принцип протокола разобран в материале «Что такое MCP».

Playwright MCP — сервер, через который Claude Code может сам открыть браузер, перейти на страницу, нажать кнопку, прочитать доступный текст и посмотреть состояние интерфейса. Вместо твоего сообщения «у меня справа пустой блок» агент получает возможность исследовать страницу непосредственно во время задачи.

Это полезно для разработки:

• после правки Claude Code открывает локальную «Змейку»;
• проверяет, что страница загрузилась без явной ошибки;
• нажимает «Старт» и осматривает новое состояние;
• делает снимок или читает структуру страницы;
• сопоставляет увиденное с твоим заданием.

Но Playwright MCP и тесты Playwright решают разные задачи.

Если Claude Code один раз открыл страницу через MCP и сообщил, что кнопка работает, это полезная текущая проверка, но не постоянная защита. После следующей правки агент может не повторить тот же путь. Сохранённый тест остаётся в репозитории и проверяет договор снова.

Лучший рабочий цикл соединяет оба подхода. Сначала агент исследует страницу через MCP, чтобы понять настоящую структуру и воспроизвести ошибку. Затем пишет короткий повторяемый тест. После исправления запускает тест и прикладывает результат. Ты получаешь и гибкость ручного исследования, и защиту на будущее.

Настройка MCP зависит от среды и установленной версии Claude Code. Не копируй случайные команды с ключами доступа и не вставляй секреты в запрос ИИ. Попроси агента использовать официальную документацию для твоей текущей установки, объяснить назначение изменяемого конфигурационного файла и не трогать другие подключения.

Playwright на Python: когда его выбирать

У Playwright есть библиотека для Python. Она умеет запускать браузер, работать со страницами и выполнять ожидания по тому же общему принципу. Если твой проект и тесты уже написаны на Python, выбирать JavaScript только ради Playwright необязательно.

Краткий пример проверки страницы на Python выглядит знакомо даже без знания синтаксиса:

from playwright.sync_api import Page, expect

def test_snake_starts(page: Page):
    page.goto("http://localhost:3000")
    page.get_by_test_id("start-button").click()
    expect(page.get_by_test_id("game-canvas")).to_be_visible()
    expect(page.get_by_test_id("score")).to_have_text("0")

Для браузерной «Змейки» на HTML и JavaScript чаще проще оставить тесты на TypeScript. Тогда приложение и проверки используют одну экосистему npm, а Claude Code не настраивает рядом второй менеджер зависимостей и отдельное Python-окружение.

Playwright Python стоит выбирать, когда:

• основная серверная часть уже написана на Python;
• команда использует pytest и хочет запускать проверки единым способом;
• в проекте уже настроены Python-зависимости и CI;
• тест связан с подготовкой данных через существующий Python-код.

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

Установка Playwright Python включает пакет и отдельную загрузку браузеров. Конкретную команду и способ фиксации зависимостей попроси Claude Code взять из актуальной официальной документации и согласовать с инструментами проекта. Это надёжнее, чем смешивать инструкции для разных языков и выпусков.

Тесты Playwright в CI при каждом пуше

CI, или непрерывная интеграция, — серверная проверка проекта после отправки изменений в репозиторий. Она выполняется не на твоём компьютере, поэтому ловит забытые зависимости, различия окружения и тесты, которые автор правки не запустил локально. Связка команд проекта и автоматического запуска подробнее разобрана в материале «npm test и CI».

Логика проверки при пуше состоит из нескольких шагов:

1. Сервер получает свежий код из репозитория.
2. Устанавливает зафиксированные npm-зависимости.
3. Загружает браузеры Playwright и нужные системные компоненты.
4. Запускает команду тестов.
5. Сохраняет HTML-отчёт и скриншоты при ошибке.
6. Помечает проверку успешной или неуспешной.

Удобно спрятать команду Playwright за стандартным сценарием npm. В package.json это может выглядеть так:

{
  "scripts": {
    "test": "playwright test"
  }
}

После этого локально и в CI используется одна команда:

npm test

Сам файл автоматизации зависит от выбранной платформы репозитория. В нём понадобятся актуальные версии служебных действий платформы, поэтому не стоит копировать их из старого материала. Попроси Claude Code создать настройку по официальному примеру Playwright для текущего проекта и показать, где выполняются эти команды:

npm ci
npx playwright install --with-deps
npm test

Первые прогоны в CI могут быть тяжелее локальных: сервер скачивает браузеры и запускает настоящее приложение. Ускорять процесс лучше после измерения. Начни с одного браузерного проекта и главных сценариев, используй кэш только по официальным рекомендациям платформы, а параллельный запуск добавляй, когда набор действительно стал долгим.

Не делай CI зависимым от твоего локального сервера или личного аккаунта. Приложение должно запускаться внутри задания CI, а тестовые данные — создаваться отдельно. Секреты хранятся в защищённых настройках платформы и передаются через переменные окружения; их нельзя записывать в тест, отчёт или репозиторий.

Если тест упал только в CI, скачай артефакты: отчёт, скриншот и трассировку. Разница часто связана с отсутствующей системной библиотекой, другим размером окна, медленным запуском сервера или данными, которые случайно остались на локальном компьютере.

Типичные проблемы Playwright-тестов

Падение теста не всегда означает дефект продукта. Иногда нестабилен сам сценарий или окружение. Задача — не добиться зелёного цвета любой ценой, а отделить настоящую поломку от слабой проверки.

Нестабильные тесты из-за таймингов

Нестабильным называют тест, который проходит и падает без изменения кода. Частая причина — жёсткая пауза:

await page.waitForTimeout(2000);

Две секунды могут быть избыточными на быстром компьютере и недостаточными в CI. Лучше ждать наблюдаемое состояние:

await expect(page.locator('[data-testid="game-canvas"]')).toBeVisible();

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

Хрупкие локаторы

Селектор вроде .container > div:nth-child(2) button привязан к внутренней вёрстке. Дизайнерская перестановка блоков сломает тест, хотя поведение для пользователя не изменилось. Playwright рекомендует выбирать элементы по роли и доступному имени, когда это возможно:

await page.getByRole('button', { name: 'Старт' }).click();

Такой локатор близок к тому, как человек и вспомогательные технологии воспринимают кнопку. Он одновременно подсказывает, если элемент перестал быть настоящей кнопкой.

data-testid полезен, когда текст меняется, переводится или не является надёжным признаком. Например, для значения счёта и канваса стабильный тестовый атрибут удобнее сложной цепочки классов. Недостаток в том, что он проверяет технический договор, а не видимую подпись.

Практическое правило:

• кнопку с устойчивым названием ищи по роли и тексту;
• поле формы ищи по подписи;
• уникальный технический элемент ищи по data-testid;
• CSS-классы оформления не используй как основной договор теста.

Тяжёлые браузеры в CI

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

Не устанавливай все браузеры только потому, что это возможно. Выбор должен отвечать реальной аудитории проекта. Когда CI ограничивает место или время, актуальные тарифы и лимиты смотри на сайте сервиса, а затем сокращай объём осознанно: меньше браузеров, меньше дублирующихся E2E-сценариев, подготовленный образ или рекомендованный кэш.

Тест зависит от случайности игры

«Змейка» использует таймеры, случайную позицию еды и клавиатурный ввод. Если тест должен случайно дождаться, пока змейка съест еду, он будет медленным и непредсказуемым. Попроси ИИ добавить безопасный тестовый режим: фиксированное начальное положение, известную еду и управляемый шаг времени. Этот режим не должен быть доступен обычному пользователю в опубликованной игре.

Состояние протекает между тестами

Один сценарий записал рекорд в localStorage, следующий увидел его и ожидал пустую таблицу. Тесты должны начинаться из известного состояния. Playwright обычно изолирует браузерные контексты, но серверная база, файлы или явно сохранённая сессия всё равно могут быть общими. Настрой подготовку и очистку именно тестовых данных.

Проверяется не тот адрес

Локальная страница работает, а тест случайно открыл опубликованную старую версию. Или CI запустил сервер на одном порту, а baseURL указывает другой. Перед сложной отладкой выведи безопасный адрес проверки и убедись, что конфиг запускает нужную сборку. Не печатай в лог адреса с токенами и другими секретами.

Падение маскируют повторным запуском

Повторный прогон полезен как диагностический сигнал: если второй запуск прошёл, тест может быть нестабильным. Но бесконечные повторы не исправляют причину. Ограниченное число повторов в CI допустимо для сбора трассировки, однако каждый нестабильный сценарий нужно разобрать и сделать предсказуемым.

Как просить ИИ написать тест Playwright и что проверить

Сильный запрос к Claude Code описывает пользовательское поведение, исходное состояние, ожидаемый результат и ограничения. Не нужно диктовать ему каждую строку кода. Сначала дай агенту изучить проект, затем потребуй маленький дифф и фактический прогон.

Готовый шаблон запроса:

Изучи текущий проект и существующие тесты. Добавь один тест Playwright на TypeScript для сценария «Змейка запускается с нулевым счётом».

Сценарий:
1. Открой главную страницу локального приложения.
2. Нажми видимую кнопку «Старт».
3. Проверь, что игровая область canvas видима.
4. Проверь, что видимый счёт равен 0.

Сначала найди реальные элементы и текущую команду запуска. Предпочитай локаторы по роли и доступному имени; для счёта и canvas при необходимости добавь стабильные data-testid. Не используй waitForTimeout и не ослабляй ожидания ради зелёного результата. Настрой baseURL и webServer только если это нужно проекту, не меняй посторонний код.

Запусти новый тест, затем весь набор. В ответе дай изменённые файлы, точные команды, сырой итог прогона и путь к отчёту или скриншоту при ошибке.

Запрос задаёт не только результат, но и границы. ИИ знает, что нельзя переписывать игру, добавлять искусственные задержки или объявлять успех без запуска.

После ответа проверь работу в несколько проходов.

1. Посмотри смысл теста

Название должно описывать поведение. Действия должны совпадать с твоим сценарием: открытие страницы, реальный клик, проверка канваса и счёта. Если тест только ищет заголовок «Змейка», он не подтверждает запуск игры.

2. Проверь локаторы

Убедись, что тест не цепляется за случайный класс оформления или порядковый номер элемента. Локатор кнопки по роли и имени понятен. data-testid для счёта тоже понятен, если такой атрибут добавлен в настоящую разметку.

3. Потребуй сырой результат запуска

Фраза «тесты проходят» не показывает, запускались ли они. Нужна команда и дословная итоговая часть вывода: сколько тестов найдено, что прошло или упало, какой код завершения вернула команда. Если проверка не запускалась из-за окружения, ИИ должен назвать точную ошибку.

4. Убедись, что тест может упасть

Временно наруши ожидание или поведение в отдельной рабочей ветке. После возврата правильного кода тест снова должен стать зелёным. Если он проходит при сломанной кнопке, значит, сценарий проверяет не то.

5. Проверь отсутствие лишних изменений

Для одного теста не требуется переписывать архитектуру игры. Посмотри список изменённых файлов. Нормальны новый тест, небольшая настройка конфига, команда в package.json и пара стабильных атрибутов в HTML. Большие изменения игровой логики требуют отдельного объяснения.

6. Отдели тест интерфейса от теста API

Playwright может наблюдать сетевые запросы, но это не значит, что любой API удобнее проверять через браузер. Если нужно отдельно убедиться, что сервер возвращает правильные данные, пригодится материал «Postman: тестирование API-запросов». Браузерный сценарий оставь для пути пользователя: нажал кнопку, запрос ушёл, результат появился на странице.

7. Запусти проверку самостоятельно

Повтори npm test на своём компьютере. Затем хотя бы один раз используй --headed, чтобы увидеть последовательность действий. Автоматический отчёт полезен, но короткий визуальный просмотр помогает заметить странный обход: например, тест кликает не по основной кнопке, а по скрытому дублю.

Хороший итог задачи — не максимальное число тестов, а маленький набор понятных договоров. Каждый сценарий должен отвечать на три вопроса: какое действие выполняет человек, какой результат считается правильным и какую реальную поломку этот тест поймает.

Частые вопросы

Playwright — это отдельный браузер?

Нет. Это инструмент, который загружает совместимые браузерные сборки и управляет ими по сценарию. Ты пишешь действия и ожидания, а Playwright организует запуск.

Нужно ли знать TypeScript, чтобы пользоваться Playwright?

Глубокие знания не обязательны, если код пишет Claude Code. Но тебе нужно уметь прочитать сценарий на уровне смысла: какой адрес открыт, куда выполнен клик и какой результат проверяется.

Можно ли записать действия без ручного написания теста?

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

Чем Playwright MCP отличается от режима с видимым браузером?

В режиме --headed выполняется сохранённый тест, а ты видишь его действия. Через MCP браузером управляет Claude Code во время исследования страницы; этот путь не станет повторяемой проверкой, пока агент не сохранит отдельный тест.

Нужно ли запускать тесты во всех браузерах?

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

Может ли Playwright проверить таблицу рекордов и API?

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

Playwright даёт тебе понятную страховку от случайных поломок: браузер сам повторяет главные действия, а ожидания фиксируют результат. Начни с запуска «Змейки», нулевого счёта и сохранения рекорда, подключи команду к CI и проси ИИ прикладывать сырой результат каждого прогона.