Как подглядывать за приемочными тестами на cucumber.js+puppeteer в докере

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

Настройки puppeteer

Для начала, нужно указать необходимые для puppeteer настройки.

const puppeteer = require('puppeteer');
puppeteer.launch({
  args,
  executablePath,
  headless,
  slowMo,
  dumpio
}).then(async browser => {
  ...
});

В моем случае я указываю следующие значения для вышеупомянутых параметров (более подробно можно почитать тут):

• args — это массив настроек, что передаются инстансу браузера. По сути это список флагов браузера, полный список флагов вы можете увидеть тут. В этом массиве я передаю следующие настройки:

1. --window-size=1920,1080 — размеры окна браузера. Так как есть понятие о размерах ViewPort и о размерах браузера, и они существуют по отдельности. Как по мне, их нужно указывать одинаково. У нового объекта страницы рекомендуется выставить viewPort размеры идентичные размеру окна, чтобы у вас не получился эффект квадрата с большими и пустыми полями вокруг. Для этого у инстанса страницы нужно вызвать page.setViewport({ width: 1920, height: 1080 }).
2. --remote-debugging-address=0.0.0.0 — установив широковещательный адрес, вы даете возможность получить доступ к протоколу отладки извне. Но так как тут не производится никакой аутентификации, то будьте осторожны. Если есть что скрывать — этот вариант не для вас. Параметр адреса, нужно использовать вместе с --remote-debugging-port=9222 это стандартный протокол. Если использовать только параметр порта, то сам отладочный протокол будет доступен только внутри докера, так как будет использован localhost или 127.0.0.1.
3. Внутри докера для разработки, чтобы не заморачиваться с правами, проще указать следующие параметры: --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 ... для прокидывания порта. Теперь можно приступить к самому подглядыванию.

Continuous deployment с помощью docker cloud

Локальный браузер как средство подглядывания

Для того, чтобы подсмотреть за тестами, нужно открыть локальный браузер Chrome на машине разработчика (не в докере) и в адресной строке набрать chrome://inspect

Вот так выглядит страница chrome://inspect

Особое внимание стоит обратить на секцию Remote Target. В ней будут отображаться удаленные цели — проще говоря открытые вкладки в докере.

Если вы запустите тесты на выполнение в докере, то после того, как будет запущен браузер, в headless режиме, внутри докера, вы увидите вкладки.

Вкладки появляются благодаря тому, что порт 9222 прокидывается из докера на localhost машины разработчика. Таким образом, при появлении на порту 9222 приемника, хром браузер детектирует удаленный инстанс в докере и запрашивает информацию о Remote Targets (Открытых вкладках). Так и происходит это волшебство. Очень удобно для разработки в VSCode Remote-Containers или в докере развернутом на машине разработчика.

Отображение вкладок, открытых внутри докера в headless браузере Chrome

В моем случае это пустая вкладка и вкладка с тестируемым веб приложением.

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

Интерфейс позволяющий видеть, что происходит на выбранной вкладке

При этом, при желании, можно взаимодействовать с элементами страницы, кликать, вводить текст и так далее. Очень удобно.

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

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

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

Демо авто-обновления списка открытых вкладок удаленного инстанса хрома в девелоперовском докере.

Демо авто обновления списка вкладок в chrome://inspect.

Демо наблюдения за ситуаций на вкладке браузера запущенного в dev докере

Еще один способ подглядывания (в случае с удаленной CI)

Этот способ хорош для отладки сценария на удаленной CI. При переходе по url https://your.ci.com:9222 или можно также перейти по url http://localhost:9222 в вашем локальном браузере, будет открыт удаленный интерфейс, расположенный на appspot.com

Но сначала, вам будет отображен список открытых вкладок. (Вместо localhost, вам нужно будет указать полный url до CI с указанием порта, на котором доступен интерфейс для отладки)

Список открытых вкладок, но не так удобно как в chrome://inspect

Приходится обновлять страницу чтобы следить за обновлением вкладок браузера.

После очередного обновления

В итоге при клике на ссылку, с названием вкладки, получаем такой же вид, как при использовании chrome://inspect, но без учета включенной темной темы.

Интерфейс chrome-devtools-frontend.appspot.com

Но соответственно, этот вариант хорош, когда вы на удаленной 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-атмосферу!