События WebDriver BiDi для стабильной автоматизации браузера
Сессии, события и границы транспорта WebDriver BiDi для сопровождаемой автоматизации браузера.
Нужна структурированная документация по теме Начало работы?
Эта статья относится к редакционной библиотеке. Для пошаговой настройки, справки и постоянных обновлений переходите сразу в соответствующий раздел docs.
WebDriver BiDi даёт стандартный канал в обоих направлениях. Клиент отправляет команду, а браузер публикует событие, поэтому тест может наблюдать навигацию, журналы, сеть и контексты без случайных пауз. Событие сообщает наблюдение браузера, но не доказывает, что приложение или сервис принял операцию.
Запуск BiDi удобно рассматривать как небольшую систему: согласованная сессия, транспорт с понятным владельцем, явные подписки и проверки видимого результата. Такие границы упрощают диагностику. В руководстве по началу работы с Playwright описан жизненный цикл браузера, а проверка взаимодействий рассматривает свидетельства за пределами события.
Разделение важно при обычном сопровождении. Тест может увидеть навигацию, запись консоли или ответ, пока приложение ещё выбирает отображение. Успешный ответ драйвера также не доказывает, что сервер принял данные. Отдельные имена для наблюдения и результата помогают отличить сбой страницы, драйвера, транспорта или сервиса.
Что меняет WebDriver BiDi
Классический WebDriver работает по запросу: клиент отправляет команду и получает ответ. BiDi добавляет длительное соединение, через которое браузер отправляет события без новой команды. Спецификация W3C WebDriver BiDi описывает команды, события и контексты просмотра.
Событие не заменяет проверку. log.entryAdded показывает наблюдаемую браузером запись консоли, но не сохранение на сервере и не успешное завершение процесса. Сетевое событие описывает категорию запроса или ответа, хотя страница может показать ошибку. Связывайте событие с минимальной проверкой ожидаемого результата.
BiDi отделяет наблюдение от реализации. Клиент подписывается на названные типы событий и может ограничить контекст просмотра. Это понятнее, чем собирать все сообщения и искать нужное позже. Подписка сама по себе не создаёт границу приватности: правила теста должны ограничивать URL, заголовки, аргументы и содержимое. Сохраняйте только нужные метаданные.
Протокол развивается, а поддержка различается у браузеров и драйверов. Сессия может подключиться, но отклонить команду, пропустить необязательное поле или закрыться при отсутствии функции. Записывайте согласованные возможности и версии. Отделяйте отсутствие поддержки от ошибки приложения, чтобы она не стала ложным тайм-аутом.
Согласуйте сессию с понятным владельцем
Создание сессии объявляет ожидания и возвращает идентификаторы для дальнейшей работы. Храните вместе настройки, профиль, политику журналов и запрошенные возможности. Запрошенная возможность не гарантирует реализацию. Читайте ответ, сохраняйте принятые значения и принимайте решения по ним.
Контексты просмотра являются границей владения. Вкладка, фрейм и новое окно могут иметь разные идентификаторы. Сохраняйте их при создании или обнаружении. При нескольких контекстах направляйте событие тесту-владельцу и игнорируйте чужие уведомления, чтобы фоновая вкладка не завершила ожидание активной.
Фикстура должна определить готовность и непригодность сессии. Это может быть успешное рукопожатие, известный контекст и подтверждение подписки. При остановке прекратите новые действия, снимите обработчики, запросите поддерживаемое завершение сессии и закройте транспорт. Путь finally нужен, поскольку callback может завершиться отдельно от команды.
Сделайте настройку повторяемой. Каждый рабочий процесс получает собственный профиль и путь артефактов; записывайте браузер, драйвер и версию протокола. Не используйте неизвестную оставшуюся сессию. Двунаправленная документация Selenium описывает клиентскую модель, а команда отвечает за данные, серверную очистку и хранение.
Подписывайтесь на события, сохраняя контекст
Подписка должна отвечать на конкретный вопрос. Для ошибки страницы фильтруйте событие журнала по контексту. Для навигации сохраняйте идентификатор, категорию URL и разрешённое время. Ранний фильтр уменьшает работу и не захватывает активность других страниц.
Обработчик по возможности не должен иметь побочных эффектов. Он может добавить ограниченную запись, завершить ожидание с именем или обновить автомат состояний. Он не должен нажимать, отправлять форму, менять хранилище или запускать новую сессию. Тогда одно событие не вызывает повторное действие и гонку.
Порядок событий имеет смысл только в пределах гарантий протокола и реализации. Запрос может прийти до отображения результата, а запись журнала после возврата действия. Используйте событие как отметку, затем ждите видимого состояния. Если допустимы разные исходы, назовите их и классифицируйте первый.
Поздние события обычны при завершении. Перед снятием обработчиков отметьте сессию закрывающейся и отбросьте сообщения после конечного состояния. Ограничьте очередь и сообщайте о переполнении. При отказе подписки запишите её имя и продолжайте лишь с утверждённым запасным вариантом, иначе укажите отсутствие возможности.
Рассматривайте транспорт как жизненный цикл
BiDi-транспорт является длительным соединением для команд, ответов и самостоятельных событий. Клиент сопоставляет ответ с идентификатором запроса и распределяет события подписчикам. Оставьте это сопоставление библиотеке; тест должен получать именованный результат, а не разбирать сырые кадры.
Разрыв возможен при ожидающей команде или во время событий. Разделяйте штатное закрытие, ошибку транспорта, сбой браузера и тайм-аут приложения. Повторное подключение не всегда безопасно: повторная отправка может продублировать действие. Повторяйте только идемпотентную подготовку по явному правилу и создавайте новую сессию, если старое состояние нельзя доказать.
Нужна политика переполнения. Много записей консоли или сетевых событий может скрыть важное сообщение. Фильтруйте при подписке, ограничивайте записи и указывайте потери. Маскируйте значения до записи в артефакт, особенно параметры URL, заголовки и аргументы. Протокол предоставляет данные, но не определяет политику хранения.
Тайм-аут должен называть остановившийся слой. Тайм-аут ответа команды, ожидания события и готовности страницы означают разное. Включайте имя, разрешённый контекст, состояние соединения и последнюю категорию. Не превращайте разрыв в общий тайм-аут страницы.
Создавайте устойчивые проверки по событиям
Начните с объявленного результата и небольшой модели. Для разрешённого заказа это могут быть синтетическая корзина, отправка, видимый статус и ограниченная запись ошибки. BiDi наблюдает навигацию или ответ, но устойчивая проверка обращается к статусу, который видит пользователь. Сначала названный результат не даёт тесту превратиться в набор удобных сигналов.
Используйте одно ожидание на переход и дайте ему смысловое имя. contextCreated завершается при появлении нужного контекста, а отдельное ожидание завершается при заголовке подтверждения. Предикаты только читают состояние, а пределы задаются конфигурацией среды. При изменении предела сохраняйте имя условия в отчёте.
Артефакт сбоя должен хранить первое отсутствующее условие. Запишите принятые возможности, действие, категорию события, владельца контекста и версии с маскированным наблюдением. Снимок подходит для утверждённой синтетической фикстуры, но полная аутентифицированная страница не нужна. В руководстве по BrowserContext Puppeteer описана похожая граница очистки.
Проверяйте отрицательные пути. Уберите сигнал готовности в синтетической фикстуре и убедитесь, что ограниченный тайм-аут называет его. Имитируйте отклонённую подписку или закрытый транспорт и классифицируйте результат как проблему среды или возможностей, а не как успех. Упражнение не требует личных данных или реальной учётной записи.
Используйте BotBrowser с ясными границами
BotBrowser может предоставить изолированные контексты и повторяемые профили для разрешённых запусков, наблюдающих WebDriver BiDi. Это помогает сравнивать одинаковые входные данные сессии и явно владеть профилем. BotBrowser не реализует протокол WebDriver BiDi, не добавляет неподдерживаемые команды или события и не гарантирует совместимость драйвера, браузера, транспорта и приложения. Реализация протокола и серверный результат остаются ответственностью выбранного стека.
Изоляция разделяет синтетическое хранилище и состояние, но сама по себе не разрешает тест. Определите доступные страницы, данные и поля событий. Профили и артефакты должны принадлежать рабочему процессу, а сессия закрываться поддерживаемым способом. Повторяемое начало улучшает сравнение, но не гарантирует событие или принятие запроса сервисом.
При использовании BotBrowser с BiDi-драйвером записывайте фактическую связку и принятые возможности. Если команды нет, связывайте ограничение с компонентом, который её отклонил. Не путайте изоляцию профиля с соответствием протоколу, а повторяемый профиль с завершённой транзакцией. Проверка продукта и соответствие протоколу должны быть раздельными.
Список проверки для команд BiDi
До запуска подтвердите владельца сессии, профиль, транспорт, возможности и подписки. Выберите контекст каждой проверки и данные, разрешённые в журналах. Назовите видимое состояние завершения и поддерживающие события. Так фикстура становится проверяемой.
Во время запуска сопоставляйте ответы команд и направляйте события обработчику с учётом контекста. Обработчики должны быть ограниченными и без побочных эффектов. Разделяйте неподдерживаемые команды, разрывы, переполнение очереди и тайм-аут страницы. Повтор допустим только с объяснимой безопасностью; при неизвестном состоянии создайте новую сессию.
После запуска закрывайте обработчики и сессию даже после ошибки проверки. Сохраняйте лишь разрешённые синтетические сведения, включая первое отсутствующее условие и принятые возможности. Сравнивайте результат и связку совместимости, а не случайные задержки. После изменения браузера или драйвера повторяйте проверки возможностей и событий.
Долговременный контракт прост: BiDi переносит команды и наблюдения, фикстура управляет сессией и транспортом, а приложение определяет завершение. Такое разделение делает ошибку точной и не превращает событие в гарантию бизнес-результата.
Команда может хранить этот контракт рядом с маршрутом: начальная команда, наблюдаемое событие, владелец контекста, понятная проверка и запасной путь. Сырые кадры не нужны; нужен контекст, чтобы различить регрессию, отсутствие возможности и потерю соединения.
В записи должен быть указан и порядок очистки. У дочернего контекста есть владелец, у подписки есть момент снятия, у артефакта есть граница синтетических данных. Это не даёт позднему событию попасть в другой тест и не оставляет профиль, меняющий следующий запуск. BiDi даёт механизм, владельцы задают политику.
Источники
Похожие статьи
Переведите BotBrowser из исследований в продакшн
Используйте эти руководства, чтобы понять модель, а затем перейти к кроссплатформенной валидации, изолированным контекстам и масштабируемому браузерному развертыванию.