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

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

• Планировщик исследует рабочее приложение и составляет план тестирования.
• Генератор преобразует один запланированный сценарий в рабочее тестовое описание.
• Исправитель запускает набор тестов, выясняет причины их неудачи и устраняет коренные проблемы.

Цель демо-программы — небольшое приложение для корзины с последовательностью действий от входа до просмотра товаров, добавления их в корзину, оформления заказа и страницы благодарности. В итоге было создано 22 автоматизированных сценария, охватывающих успешные сценарии работы, негативные случаи и крайние ситуации проверки. Они запускаются параллельно на основе объектов страниц, которые сами агенты поддерживают. Отчет Playwright в формате HTML показал 22 пройденных теста, 0 неудач и 0 нестабильных результатов; вся серия тестов была выполнена за 16,2 секунды.

Подготовительные шаги перед запуском любого агента

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

Тестовый сервер MCP Playwright. Агенты не должны догадываться о структуре DOM, поэтому они используют реальный браузер. Один файл конфигурации связывает их между собой:

{
  "servers": {
    "playwright-test": {
      "type": "stdio",
      "command": "npx",
      "args": ["playwright", "run-test-mcp-server"]
    }
  }
}

Это предоставляет каждому агенту такие инструменты, как browser_navigate, browser_snapshot и browser_click, а также test_run и test_debug для функции Healer.

Контракт фреймворка. Один файл framework.md определяет структуру папок и правила: селекторы находятся в pages/, сценарии использования — в flows/, а адреса и учетные данные — в .env. Каждый агент читает его перед выполнением действий, благодаря чему результаты выглядят как единая кодовая база, а не три разных стиля.

Тест-зерно. Один небольшой спецификационный документ открывает реальную главную страницу и проверяет наличие стабильных свойств. Каждый сгенерированный тест начинается с этого известного рабочего состояния.

Качество агента зависит только от основы, на которой он работает, и эти три элемента и являются такой основой.

The Planner: определение того, что заслуживает тестирования

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

Его алгоритм работы:

1. Один раз вызывается функция planner_setup_page.
2. Исследование производится с помощью инструментов браузера; читаются снимки DOM вместо скриншотов.
3. Выделяются основные сценарии использования и способы их сбоя.
4. План в формате Markdown сохраняется в файл specs/-plan.md.

Каждый сценарий в плане имеет заголовок, пронумерованные шаги, ожидаемый результат, предположение относительно начального состояния (чистая сессия, если не указано иное) и путь к файлу, в котором он будет сохранен.

В итоге было выделено 22 сценария, разделённых на части для входа, корзины, оформления заказа и одного полного цикла от начала до конца. Такая структура оказывается полезной позже, поскольку генератор преобразует название каждой части в блок test.describe, и план с кодом автоматически остаются согласованными.

Зачем отдельный этап? Охват тестами — это задача, требующая размышлений. Когда необходимо одновременно планировать и писать код, процесс планирования ухудшается. Вариант с только планом позволяет его проверить и отредактировать ещё до того, как появится хотя бы одна строка кода теста.

Генератор: воплощение одного сценария

Генератор обрабатывает по одному сценарию за раз, никогда не всё плановое задание целиком. Для каждого сценария он:

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

Читает лог выполнения с помощью generator_read_log, который содержит информацию о местоположениях и указания на те операции, которые действительно сработали.

Вызывает generator_write_test для создания одного файла спецификации.

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

Результат автоматически соответствует правилам фреймворка:

// spec: specs/checkout-e2e-plan.md
// seed: tests/web/seed.spec.js

import { test, expect } from '../../../fixtures';
import { users } from '../../../testdata';test.describe.configure({ mode: 'parallel' });test.describe('E2E checkout journey', () => {
  test('positive: login → add product → checkout → thank you → home', async ({ flow }) => {
    await flow.completeHappyPathPurchase();
  });
});

В результатах отсутствуют CSS-селекторы, текстовые пароли и строки URL. Селекторы перемещаются в объекты страниц, а многоэтапные процессы превращаются в методы класса потока:

async completeHappyPathPurchase(user = users.standard, info = checkout.valid) {
  await this.goToCheckoutInformation(user);
  await this.fillValidInformation(info);
  await this.continueToOverview();
  await this.app.checkoutOverview.expectProductVisible(products.first.name);
  await this.finishOrder();
  await this.backHomeToProducts();
}

Каждый тест также получает собственный контекст браузера, граф объектов страницы и экземпляр потока через фикстчеры. Благодаря отсутствию общего изменяемого состояния набор тестов с самого начала безопасен для параллельной работы, а не добавляется позже. Именно это отличает скрипт от фреймворка.

Healer: устранение проблем на правильном уровне

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

1. test_run запускает набор тестов и собирает информацию о сбоях.
2. test_debug останавливается на каждом сбое.
3. Он анализирует текущий скриншот, консоль, сетевой трафик и несработавшее утверждение.
4. Он диагностирует причину: изменение локатора, смещение во времени, изменение спецификации или настоящая ошибка продукта.

Он устраняет причину проблемы, а не её симптомы: обновляет папку pages/, когда меняется интерфейс, и папку api/endpoints/, когда меняется структура контракта.

Затем он снова запускает этот тест и переходит к следующей неудаче.

Два механизма контроля обеспечивают его надёжность. Он никогда не ослабляет условия проверки лишь для того, чтобы тест прошёл успешно. Если продукт содержит ошибку, а тест — правильный, он помечает тест функцией test.fixme() и добавляет комментарий с описанием реального поведения, чтобы неудача оставалась видимой и не терялась среди других результатов. Кроме того, он избегает использования таких ненадёжных API, как networkidle, в качестве временного решения проблемы с конкурентным доступом.

Преимущество заключается в концентрации изменений. Достаточно переименовать кнопку — будет отредактирован один метод объекта страницы, после чего все тесты, использующие его, снова будут работать. Поскольку 22 теста используют 325 строк кода объектов страницы, распределенных по 10 классам, переработка не приводит к срыву всего набора тестов. В целом каждый компонент отвечает за четко определенную часть репозитория, а совместный слой объектов страницы обеспечивает стабильность всей системы.

Запуск от начала до конца

Команды на настройку:

1. Copy .env.example → .env, set BASE_URL (+ credentials)
2. npm install && npx playwright install

И агент выполняет действия в следующем порядке:

3. Run the Planner
      → specs/checkout-e2e-plan.md   (22 scenarios, reviewed by me)4. Run the Generator, scenario by scenario
      → tests/web/login/login.spec.js
      → tests/web/cart/cart.spec.js
      → tests/web/checkout/checkout.spec.js
      → tests/web/e2e/checkout-journey.spec.js5. npm test        (4 workers, fully parallel)6. Any red? Run the Healer → re-run → green

Переход на другой продукт не влияет на агентов. Установите BASE_URL на новый продукт, заново создайте объекты страницы и тестовые данные, затем снова выполните три те же команды. Поскольку агенты читают файлы framework.md и .env, а не жестко заданное название продукта, данная система является переносимой и не специализированной под конкретный случай.

Насколько на самом деле быстрее?

Утверждения вроде «Благодаря ИИ скорость увеличилась в десять раз» не следует принимать без детального объяснения. Ручная разработка тестов от начала до конца редко сводится к простому вводу текста. Это подразумевает открытие DevTools, поиск стабильного селектора, нахождение кнопки в необычной оболочке, повторную загрузку для проверки слишком раннего выполнения проверки и начало всего заново. Большая часть усилий приходится на этот цикл поиска, а генератор снижает его нагрузку, выполняя шаги в реальном времени и сообщая о том, что сработало.

Преимущества проявляются на нескольких этапах:

• Определение охвата тестирования. Вручную это делается спорадически, и часто упускаются негативные случаи. Инструмент Planner заранее перечисляет положительные, негативные и граничные сценарии.
• Поиск локаторов. Ручной поиск элементов с помощью DevTools заменяется использованием локаторов, сохранённых из уже пройдённой сессии.
• Первый успешный тест. Цикл «записать, запустить, исправить и повторить» превращается в генерацию тестов на основе проверенного текста.
• Поддержание актуальности набора тестов. Поиск сломанных селекторов в каждом техническом задании заменяется одной корректировкой объекта страницы, которая исправляет все зависимые тесты.

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

Скорость выполнения обусловлена совершенно другими факторами. Параллелизм — это не функция ИИ; это правило проектирования, которое агенты должны соблюдать. Каждый тест получает новый контекст из фикстур, и ни один из них не изменяет состояние общего модуля, поэтому конфигурация работает полностью параллельно: четыре рабочих процесса локально, два в CI с двумя попытками повторного запуска, причем трассировки и видеозаписи создаются только при сбое теста. Любой набор тестов, использующий одну сессию входа, не может работать таким образом без рисков. Этот набор может, потому что правило «один сценарий — один независимый тест» было обязательным для соблюдения генератором в каждом файле.

Четыре урока, которые стоит перенять

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

Использование выполнения на уровне доверия к памяти. Локаторы, подтвержденные в работающем браузере, надежнее тех, которые предполагаются на основе документации.

Создайте каркас до реализации агентов. Объекты страниц, фикстчеры, обработка среды и правила параллельной работы — вот что превращает вывод ИИ в рамочную структуру, а не в набор скриптов. Написание файла framework.md улучшило качество больше, чем любые корректировки запросов.

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

Для кого это подходит

Инженеры по тестированию, которые тратят больше времени на устранение ошибок в механизмах поиска, чем на разработку методов покрытия тестами, почувствуют преимущества. Также это будет полезно командам, использующим Playwright и желающим внедрить ИИ в строгую структуру без замены существующих методов, а также всем, кто сравнивает агентов Copilot или Cursor с тестовым сервером MCP от Playwright.

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