Как подглядывать за приемочными тестами на cucumber.js+puppeteer в докере
Запуская тесты в контейнере, иногда нужно подглядеть за тем как ведет себя сценарий в браузере, который запущен внутри докера. Как это сделать, речь пойдет ниже.
Настройки puppeteer
Для начала, нужно указать необходимые для puppeteer настройки.
const puppeteer = require('puppeteer');puppeteer.launch({
args,
executablePath,
headless,
slowMo,
dumpio
}).then(async browser => {
...
});
В моем случае я указываю следующие значения для вышеупомянутых параметров (более подробно можно почитать тут):
args
— это массив настроек, что передаются инстансу браузера. По сути это список флагов браузера, полный список флагов вы можете увидеть тут. В этом массиве я передаю следующие настройки:
--window-size=1920,1080
— размеры окна браузера. Так как есть понятие о размерах ViewPort и о размерах браузера, и они существуют по отдельности. Как по мне, их нужно указывать одинаково. У нового объекта страницы рекомендуется выставить viewPort размеры идентичные размеру окна, чтобы у вас не получился эффект квадрата с большими и пустыми полями вокруг. Для этого у инстанса страницы нужно вызватьpage.setViewport({ width: 1920, height: 1080 })
.--remote-debugging-address=0.0.0.0
— установив широковещательный адрес, вы даете возможность получить доступ к протоколу отладки извне. Но так как тут не производится никакой аутентификации, то будьте осторожны. Если есть что скрывать — этот вариант не для вас. Параметр адреса, нужно использовать вместе с--remote-debugging-port=9222
это стандартный протокол. Если использовать только параметр порта, то сам отладочный протокол будет доступен только внутри докера, так как будет использованlocalhost
или127.0.0.1
.- Внутри докера для разработки, чтобы не заморачиваться с правами, проще указать следующие параметры:
--no-sandbox
(все процессы в chrome запускаются в песочнице, но для тестов нам нечего бояться, мы не будем посещать опасные сайты) и--disable-setuid-sandbox
(отключаем установку битаsetuid
для песочницы, так как у меня Linux в докере — это актуально). Эти два ключа исключают проблемы при использовании root учетной записи, для запуска браузера.
headless
— у меня установлен вtrue
по умолчанию. Так как внутри докера не хочется использоватьxvfb
для запуска графического интерфейса google chrome в фоне. Но в некоторых случаях, как например, тестирование расширений, нужен xvfb, так как некоторые диалоги и функции не доступны в режимеheadless
.executablePath
— если устанавливать стабильную версию браузера google-chrome черезapt-get
, то он будет доступен какgoogle-chrome-stable
.slowMo
— а вот это уже важный ключ для подсматривания в докере за тестами. Так как замедляет операцииpuppeteer
на указанное кол-во миллисекунд. Благодаря этому замедлению, вы сможете в деталях рассмотреть действияpuppeteer
в браузере и возможно даже понять причину падения степа или сценария.dumpio
— позволяет видеть вывод ошибок и логов процесса браузера. (на любителя)
Настройки вашего докер образа
Итак, с настройками puppeteer
мы закончили. Теперь у нас есть доступ к удаленному отладочному интерфейсу. Но порт все еще остается закрытым от удобного доступа через localhost
и конечно же, нужно прокинуть порт 9222
на нашу машину в настройках докера. Так как я использую VSCode Remote-Containers
расширение, то мне достаточно прописать "appPort": [9222]
внутри .devcontainer/devcontainer.json
. Если вы используете просто Docker, то можете использовать параметры docker run -d -p 9222:9222 ...
для прокидывания порта. Теперь можно приступить к самому подглядыванию.
Локальный браузер как средство подглядывания
Для того, чтобы подсмотреть за тестами, нужно открыть локальный браузер Chrome на машине разработчика (не в докере) и в адресной строке набрать chrome://inspect
Особое внимание стоит обратить на секцию Remote Target. В ней будут отображаться удаленные цели — проще говоря открытые вкладки в докере.
Если вы запустите тесты на выполнение в докере, то после того, как будет запущен браузер, в headless режиме, внутри докера, вы увидите вкладки.
Вкладки появляются благодаря тому, что порт 9222
прокидывается из докера на localhost машины разработчика. Таким образом, при появлении на порту 9222
приемника, хром браузер детектирует удаленный инстанс в докере и запрашивает информацию о Remote Targets (Открытых вкладках). Так и происходит это волшебство. Очень удобно для разработки в VSCode Remote-Containers или в докере развернутом на машине разработчика.
В моем случае это пустая вкладка и вкладка с тестируемым веб приложением.
Для того, чтобы посмотреть, что происходит во вкладке, нужно кликнуть на inspect
ссылку под названием интересующей табы браузера. При этом будет открыт UI интерфейс.
При этом, при желании, можно взаимодействовать с элементами страницы, кликать, вводить текст и так далее. Очень удобно.
Единственное неудобство - это отсутствие возможности автоматически обновлять контент выбранной вкладки, при начале следующего сценария. Приходится закрывать окно с закрытой вкладкой и снова кликать на inspect
ссылку под нужной вкладкой. Но это не так сложно делать.
Если вкладка будет закрыта на удаленном инстансе барузера, то интерфейс текущей вкладки, будет затенен и будет как бы намекать на завершение сеанса работы с вкладкой и наблюдения за тем, что в ней происходит.
Демо авто-обновления списка открытых вкладок удаленного инстанса хрома в девелоперовском докере.
Еще один способ подглядывания (в случае с удаленной CI)
Этот способ хорош для отладки сценария на удаленной CI. При переходе по url https://your.ci.com:9222
или можно также перейти по url http://localhost:9222
в вашем локальном браузере, будет открыт удаленный интерфейс, расположенный на appspot.com
Но сначала, вам будет отображен список открытых вкладок. (Вместо localhost, вам нужно будет указать полный url до CI с указанием порта, на котором доступен интерфейс для отладки)
Приходится обновлять страницу чтобы следить за обновлением вкладок браузера.
В итоге при клике на ссылку, с названием вкладки, получаем такой же вид, как при использовании chrome://inspect, но без учета включенной темной темы.
Но соответственно, этот вариант хорош, когда вы на удаленной CI запускаете тесты, так как вариант с chrome://inspect работать в этом случае не будет. Вы также можете использовать мышь и клавиатуру для ввода данных или выделения определенного значения, чтобы проверить гипотезу об обнаруженной проблеме.
Когда вкладка внутри докера будет закрыта, то UI devtools, оповестит вас об этом вплывающим сообщением.
Проект devtools-frontend UI
Сам проект UI интерфейса, расположен на github.com.
Chrome Remote Debugging Protocol
Благодаря этому протоколу, возможна удаленная отладка и взаимодействие с элементами браузера. Репозиторий также находится на github.com.
Более подробней об автоматизации при помощи данного протокола, можно узнать из доклада на youtube.
Многие разработчики знакомы с мощным Chrome DevTools, который помогает нам проверять, профилировать и отлаживать наши веб-приложения. Но знаете ли вы, что Chrome предоставляет практически всю ту же информацию и возможности через API, который вы можете использовать в JavaScript?
В этом выступлении мы рассмотрим, как вы можете начать использовать Chrome DevTools Protocol сегодня, чтобы разблокировать мощные методы автоматизации для вашего веб-приложения. Мы расскажем, как начать использовать протокол через Puppeteer, а затем подробно рассмотрим некоторые действительно интересные возможности, которые открываются при его использовании в сочетании с безголовыми браузерами, такие как целостное сквозное тестирование, сбор кода и использование кода. метрики и новые сервисные парадигмы.
Полезные ссылки
- https://github.com/GoogleChrome/puppeteer/issues/737
- https://github.com/cyrus-and/chrome-remote-interface/blob/master/README.md
- https://developers.google.com/web/tools/chrome-devtools/
- https://developers.google.com/web/updates/2017/04/headless-chrome
Заключение
Очень классно, что сейчас можно при использовании удаленного запуска браузера в докере, все равно иметь возможность подсмотреть за тем, что происходит с контентом вкладки. Все это благодаря CRDP (Chrome Remote Debugging Protocol). Надеюсь вам тоже пригодятся эти инструменты, в откладке ваших сценариев и в поиске причин падения степа или сценария.
P.S. А еще у вас есть отличная возможность подглядывать за контентом всей команды Mad Devs:
Блог — делимся ништяками, лайфхаками и экспертизой, полученной исключительно на личном опыте каждого члена нашей команды!
Инстаграм — делимся нашими рабочими процессами и
рок-н-рольным настроением!
Подпишитесь и почувствуйте нашу Mad-атмосферу!