Совсем недавно вышла статья про новый инструмент Playwright, одним из авторов которого является Андрей Лушников. Нам выпала возможность пообщаться с Андреем и задать все вопросы, которые внимательные читатели написали в комментариях. Думаю, в этом лонгриде они смогут найти ответы. Немного спойлеров:
- Андрей рассказал историю развития Playwright и Puppeteer;
- ответил на вопросы про протоколы, которые используют для работы с браузерами;
- рассказал про сложности браузерных движков и планируемые интеграции Playwright.
Андрей Лушников приедет в Санкт-Петербург 8-9 апреля на конференцию Heisenbug, где и у вас будет возможность задать ему вопросы.
В интервью участвовали: Владимир Ситников vladimirsitnikov (программный комитет Heisenbug), Евгений Трифонов phillennium (журналист JUG Ru Group), Всеволод Брекелов (PMM конференции Heisenbug).
Кроссбраузерный шпагат
Евгений: У меня есть вводный вопрос. Когда я сталкиваюсь с проектом вида Playwright и вижу слово «кроссбраузерный», вспоминается реклама с Ван Даммом на шпагате между двух грузовиков.
У меня ощущение, что делать один такой инструмент, чтобы он работал с разными браузерами на разных языках, — тоже должны быть такие шпагаты. Интересно поговорить, где они и как выглядят главные технические челленджи.
Андрей: Да, таких шпагатов действительно много. Нам, как пользователям, многие вещи кажутся понятными и естественными, а на деле это не так. Например, такая простая вещь, как нажатие на ссылку.
Вот я нажал на ссылку — а ссылка возьми и прокрути страничку к какому-нибудь интересному месту. URL вроде бы и поменялся, но сайт-то все тот же. Это навигация или не навигация? С точки зрения человека — вполне, а с точки зрения браузера есть разные навигации: same-page navigation, когда документ не пересоздается, и new document navigation — когда страница загружается заново. Same-page navigations всегда были головной болью для Web Automation, и в нашу эпоху SPA (single page application) и массового использования History API жизнь проще не стала.
Сделать так, чтобы всё это управлялось одним API, ввести формализацию, чтобы люди не удивлялись, как что работает, — довольно сложно. Это первый челлендж.
Но мало придумать API, надо это API еще как-то поддержать во всех браузерах: Chromium, WebKit и Firefox. Для этого мы занимаемся «инструментацией» браузерных движков и разрабатываем браузерные дебаггинг-протоколы. Результаты этой работы — Chrome DevTools Protocol в Chromium, Juggler в Firefox, и WebInspector Protocol в WebKit. Дебаггинг-протоколы с одной стороны должны быть достаточно мощными, чтобы мы могли реализовать нужное нам API, а с другой стороны — простыми в поддержке для браузерных разработчиков.
Например, та же навигация внутри WebKit и Chromium технически реализована очень по-разному. Мы много общались с ребятами из WebKit и в итоге договорились на инструментацию, которая кардинально отличается от хромовской, но все еще удовлетворяет наши потребности в Web Automation. Так вот, поиск таких технических компромиссов между API и возможностями по инструментации трех разных браузеров — это действительно сложно, но очень интересно.
Что касается технических челленджей, то самый главный — это кроссплатформенный WebKit. В дикой природе вебкит встречается в основном в виде Safari и только на macOS/iOS. Но не у каждого разработчика есть Mac, поэтому наша задача была сделать билды вебкита на Mac, Linux и Windows, и благодаря этому теперь можно гонять свои веб-тесты на каком-нибудь дешевом linux-based CI во всех трех браузерах.
Всеволод: А WebKit сейчас Apple поддерживает или кто-то ещё?
Андрей: Насколько мне известно, WebKit развивается в основном силами Apple и компании Igalia.
У WebKit есть множество разных портов под разные платформы. Igalia в основном занимается linux-портами WebKitGTK и WebKitWPE, а также занимается браузером Epiphany.
Что касается WebKit на Mac — это, конечно же, Apple.
На Windows есть два порта. Первый — Webkit-on-Windows, который Apple вроде бы сделала для iTunes на Windows. Этот порт не особо развивается. Второй порт WebKit Cairo. Им в основном занимается Sony.
Как это было? Какие протоколы используются?
Всеволод: Один из читателей предыдущей статьи отметил, что есть нюансы с Mozilla. У них же там не DevTools протокол, правильно, а свой какой-то? По крайней мере, год назад была переписка, что вы хотите сделать API такой же, как для Puppeteer.
Андрей: Нюанс действительно есть :) Для нужд Playwright мы самостоятельно разрабатываем Juggler — дебаггинг-протокол для Firefox, идеологически похожий на Chrome DevTools Protocol, однако им не являющийся. Почему так?
Дело в том, что Chrome DevTools Protocol очень низкоуровневый протокол: это позволяет клиентам протокола получать максимум от взаимодействия с браузером, но так как браузер развивается и меняется, протокол меняется вместе с ним. Для эффективного использования Chrome DevTools Protocol нужно быть немного браузерным инженером: знать, где почитать исходники и понимать, как что устроено. К сожалению, Chromium — большой и сложный проект, правильно использовать Chrome DevTools Protocol сложно, а поспевать за изменениями в протоколе — и вовсе вечный крест. Большинство программ, нетривиально использующих Chrome Devtools Protocol, не получают должной поддержки, и через полтора-два года после своего создания перестают работать с новыми версиями Chromium. Отчасти это и побудило нас в свое время создать Chrome Puppeteer как стабильный API для Chromium Automation.
Juggler — это наше видение мощного дебаггинг-протокола для файерфокса, который просто поддерживать и в который мы вложили весь наш опыт работы над дебаггинг-протоколом в Chromium.
Когда мы показали Juggler команде Firefox, было много воодушевления. Дело в том, что в Firefox уже есть несколько протоколов: marionette, который используется для нужд Selenium, и Remote Debugging Protocol — используется для нужд Firefox DevTools. Однако эти протоколы по разным причинам не удовлетворяют нужды web automation.
Мы продолжаем развивать и поддерживать наш Juggler.
С другой стороны, было много обсуждений. В конце концов, несмотря на все наши сомнения в технической осуществимости, команда Firefox решила начать новый проект — Remote Protocol, целью которого стала реализация непосредственно самого Chrome DevTools Protocol в Firefox. Если у них получится — что ж, будет здорово! Мы перейдем на их реализацию и будем использовать у себя в Playwright. А пока мы продолжаем развивать и поддерживать наш Juggler.
Всеволод: Как мы поняли, ты делал и Juggler, и Puppeteer. Хотелось понять: переход на Playwright означает, что весь API Puppeteer будет поддерживаться в Playwright?
Андрей: Краткий ответ — все так! Если подробнее, то API в Playwright либо такое же, как в Puppeteer, либо лучше :)
Когда мы начинали заниматься Puppeteer, мы толком не знали, что делаем. Мы всю жизнь занимались Chrome Developer Tools, делали инструментацию браузера и разрабатывали Chrome Devtools Protocol. И тут вдруг такая тема — web automation! Решили посмотреть, что там бывает, а там какой-то PhantomJS, какой-то непонятный мир.
В Playwright мы хотим заточить API так, чтобы люди писали тесты, и им было легко, красиво и понятно.
По образу и подобию старших братьев мы сделали Puppeteer, особо ни под что не затачивая. Назвали «general purpose browser automation library», чтобы люди понимали — для чего хочешь, для того и используй. Очень быстро выяснилось, что многие используют для тестирования, а для тестов как раз API было не очень эргономично. Люди много ошибались.
Например, то, что вообще нужны браузерные контексты, мы поняли только через полтора года (браузерные контексты появились в Puppeteer v1.5.0). У людей было много тестов, внутри тестов создается другая страничка, первую при этом нужно закрывать, а вторая остается, странички накапливаются, память утекает, куки застревают. В общем, беда.
В Playwright мы уже научены опытом и стремимся решить многие из важных проблем Puppeteer. Например, в Playwright контексты — центр всего, без контекста даже страничку не создать. Любой тест начинается с создания браузерного контекста и заканчивается его закрытием. Другой пример: контексты в Playwright позволяют задать множество настроек, которые наследуются всеми страницами, в том числе и попапами. В рамках Puppeteer эта задача нами так и не была решена.
В Playwright мы хотим заточить API так, чтобы люди писали тесты, и им было легко, красиво и понятно.
Всеволод: Ты сказал, что вы хотите, чтобы людям было удобно, и вы смотрели, как используют Puppeteer. Вы смотрели на сценарии, исследовали, как люди используют Puppeteer при разработке Playwright? И если да, то как это повлияло на разработанные API?
У нас хорошее представление о том, где ошибаются люди и где у них возникают проблемы.
Андрей: Во время Puppeteer так сложилось, что люди задавали вопросы не на StackOverflow, а на нашем багтрекере. На все эти вопросы мы старались отвечать, многие меня знают именно по ответам в нем. Так что да, думаю, у нас хорошее представление о том, где ошибаются люди и где у них возникают проблемы.
Всеволод: А была ли такая штука, которую люди очень просили, но это не входило в ваши планы? Вам казалось, что это не нужно или это можно было сделать как-то по-другому?
Андрей: Да, есть такое, о чем я сожалею до сих пор. В Puppeteer есть метод page.goto. Когда мы начинали, мы называли его page.navigate, это казалось очень правильным решением. А потом пришли ребята и сказали, что во всём мире goto, сделайте тоже goto, писать четыре буквы гораздо быстрее.
Всеволод: А почему это не очень?
Андрей: Я как браузерный человек: у нас есть навигация, знаем, что страничка навигируется, и понимаем процесс — начинаем навигацию. Что такое goto? Pascal какой-то. (ссылка от бумера)
Как будет развиваться Playwright
Всеволод: Да, Pascal я вспоминаю =) А какие основные задачи для технической команды вы видите на текущие полгода-год? Может, какие-то основные фичи ещё остаётся впилить или решить какие-то серьезные проблемы?
Андрей: У нас сейчас две основные задачи.
Первая задача — upstream наших изменений в браузеры, то есть доработка стоковых браузерных дебаггинг-протоколов. Мы продолжаем разговаривать с Firefox на тему Juggler vs Chrome Devtools Protocol, и мы активно коммитим код в WebKit.
Вторая задача — выпустить версию 1.0 к лету. Это API будет с нами на долгие годы вперед, так что мы не спешим.
О сложностях в браузерных движках
Всеволод: Я нашел ссылку на GitHub у вас в документации, и там тоже можно посмотреть, сколько текстов на каких браузерах падает. Очень удобная вещь. Правильно ли я понимаю, что там есть очень сложные тесты, которые нужно пофиксить?
Например, я увидел один тест, который помечен «skipped» для запуска c WebKit и не на MacOS, и он должен работать с каким-то регулярным текстом. Правильно ли я понимаю, что есть какое-то отличие между запуском теста с MaсOS, Linux, Unix, именно это имеется в виду в тесте?
Андрей: Да, такие отличия есть. В браузерах есть достаточно много платформо-специфичного кода, так что иногда мы находим какие-то проблемы в инструментации браузера на конкретной операционной системе. На каждую такую проблему мы добавляем regression-test в Playwright — похоже, речь как раз об одном из таких тестов.
Мы — браузерные разработчики, поэтому операционная система для нас очень важна, и мы гоняем наши тесты на всех операционных системах. Например, WebKit на каждой платформе использует свою реализацию network-стека. Headless-режимы браузеров тоже очень по-разному реализуются на разных платформах — и все это наша зона ответственности.
А вот для веб-разработчиков операционная система пользователя не так важна. Да, есть какие-то отличия в инпуте — вон на маке кнопка Command, а на линуксе вместо нее — Ctrl. Рендеринг шрифтов еще отличается от платформы к платформе. Но в основном можно гонять свои веб-тесты на линуксе и спать вполне спокойно.
Всеволод: Как работает Playwright с эмуляцией девайсов?
Андрей: Мобильная эмуляция работает очень хорошо. Мы начинали заниматься ей еще во времена Chrome Developer Tools, когда делали «device mode». Там мы много чего узнали, и с этим опытом уже делали эмуляцию в других браузерах для Playwright.
Playwright эмулирует различные свойства веб-платформы, такие как meta viewport tag, размер viewport, touch events, useragent. Сайт, открытый со включенной эмуляцией, скажем, айфона, будет выглядеть и работать так же, как на настоящем айфоне. А если вдруг это где-то не так, то это баг, зафайлите его пожалуйста, мы починим.
Как запускать c Continuous Integration
Всеволод: Мы уже обозначили, что можно запускать всё подряд с определенными нюансами. Я знаю, что для Selenium есть много инструментов, например Selenoid. Как быть в случае с Playwright, если мы хотим запускать параллельно 100500 тестов?
Андрей: Тут смотря что именно и как именно хочется параллелить. Если, например, у меня 1000 тестов, и я хочу прогнать их как можно быстрее на одном браузере — то в Playwright есть браузерные контексты. Открывай себе каждый тест в своем контексте, а после теста закрывай контекст — и всё. Так, например, работает jest-playwright.
Если мы, например, хотим прогнать наши тесты параллельно в двух браузерах на одной ОС, то нам ничего не мешает запустить эти два браузера параллельно и гонять в них тесты.
А вот если, например, мы хотим прогнать наши тесты параллельно на разных ОС, то тут помогают современные CI/CD, в которых очень просто запустить одну и ту же таску на разных ОС. Тут, конечно, важно, что Playwright без проблем работает на этих самых современных CI/CD.
Если говорить конкретно про Selenoid, то этот сценарий, когда тест исполняется у меня локально, а браузеры живут где-то вдалеке в виде сервиса — технически возможен и с Playwright. Однако сам юзкейс во многом, на мой взгляд, уходит в прошлое.
Всеволод: Я правильно понимаю, что для запуска в докере нужно создать image docker, с которого запускается Node.JS и Playwright — и всё готово?
Андрей: Да, всё так.
Владимир: А если эти браузеры ставить каждый раз — это не долго будет? И как происходит установка?
Андрей: Мы стараемся, чтобы по всему миру браузеры скачивались быстро — у нас для этого хороший глобальный CDN. На моем компьютере в офисе все три браузера скачиваются секунд за 30. На CI тоже получается быстро, к тому же много где можно закэшировать node_modules.
Что касается установки, то у нас она не в систему, а локальная, просто бинарник с браузером распаковывается в правильное место. Это много времени не занимает и операционную систему никак не «загрязняет».
О доверии пользователей к пропатченным браузерам в тестах
Всеволод: У людей бывает недоверие, что там за штука и что качает. Раньше, как я помню, в Puppeteer была возможность выбрать версию браузера. А тут, как я понимаю, вы предлагаете решение, где сами определяете для разных платформ (Chromium, WebKit или Firefox) драйвер или браузер, сами его кладёте и всё время используете последнюю версию?
Андрей: Мне кажется, ты имеешь в виду переменную среды PUPPETEER_CHROMIUM_REVISION. В Playwright мы этого пока не добавляли, нам кажется, что в ней нет необходимости.
В мире Playwright пользователи всегда могут выбрать версию Playwright, которую они хотят использовать, и она с собой притянет правильные браузеры. Если хотите обновить браузеры — просто обновляете версию библиотеки. Такая система позволяет нам значительно сократить пространство для багов и несоответствий, а для пользователей — меньше мороки с настройкой системы.
Владимир: У вас не бывало такого, что говорят: «У вас тут браузеры свои пропатченные, а мы пользуемся обычными, как нам правильно узнать, что у вас там пропатчено?»
Андрей: Ой, да, бывало :) Все наши изменения для браузеров лежат в нашем репозитории, в папке browser_patches. Всё опенсорсное, и любой желающий может посмотреть.
Мы занимаемся только инструментацией браузеров — и ни в коем случае не трогаем сам Rendering Engine.
Тут важно, что мы занимаемся только инструментацией браузеров — и ни в коем случае не трогаем сам Rendering Engine. Так что наши сборки браузеров отображают web точно также, как стоковые. И при этом мы активно работаем с браузерными вендорами, чтобы все наши изменения в конечном итоге оказались в стоковых браузерах.
О возможных интеграциях и едином кроссбраузерном протоколе
Всеволод: Вы думали как сделать так, чтобы было какое-то портирование Selenium-тестов на Playwright?
Андрей: Если мы говорим про Selenium-тесты, то нужно понять, на каком языке. Но вообще мы думали, да. Весь Puppeteer был на JavaScript, и очень быстро пришло комьюнити и сделало Puppeteer для Python, для C#, Ruby, Rust и всего остального.
Похожая ситуация получается и с Playwright. Например, автор Puppeteer C# сейчас занялся разработкой Playwright C#, чему мы очень рады. Так что для поддержки разных языков мы в основном полагаемся на комьюнити.
Всеволод: А вы постепенно интегрируетесь с какими-то другими тулами? Я из вашего slack-канала узнал о замечательном инструменте QAWolf, лично его ни разу не использовал и о нем не слышал. Инструмент показался мне интересным. Насколько я понял, внутри у вас кто-то его использует и пытается заинтегрироваться. Есть ли ещё какие-то инструменты в активной интеграции?
Андрей: QAWolf хороший пример. Из больших проектов, которые уже используют Playwright, можно назвать Typescript и VSCode. Тестовый фреймворк CodeceptJS тоже недавно поддержал Playwright в качестве одного из драйверов.
А вообще у нас есть отдельная страничка-витрина с проектами вокруг Playwright. Если вы используете Playwright и хотите поделиться этим с миром — присылайте нам PR и добавляйтесь на эту страничку.
Всеволод: Я знаю, что у Selenium есть IDE. Думаете ли вы о том, чтобы запилить какой-нибудь плагин к VS Code или к другой IDE, чтобы те, кто использует IDE, могли бы легко начать писать тесты на Playwright? Думаете ли вы о подходе с плагинами, чтобы люди легче заходили в область тестирования?
Андрей: Что касается Selenium IDE — нам интересна эта тема, и у нас даже есть несколько классных экспериментов в этой области, но пока мы только прощупываем почву. Кроме того, мы сейчас полностью сконцентрированы на Playwright, и все силы отдаем в него.
Что касается плагинов к VSCode — нет, мы сами этим не занимаемся, но надеемся на комьюнити. То же самое и про другие IDE.
А вот просто плагины для Playwright писать можно. И самое важное, это возможность делать свои собственные «движки селекторов» — описывать алгоритмы выбора какого-либо элемента на странице. Так, например, CSS и XPATH — это движки селекторов.
Комьюнити уже сделало движок селекторов с поддержкой Shadow DOM. Очень интересно было бы увидеть движки, заточенные под UI-фреймворки — например, движок селекторов для React, который опирается на иерархию компонентов, а не на DOM. Ждем!
Владимир: Замечу, что пул-реквестов закрыто почти 800, а issues всего 100-200. Почему так? У вас реально всё работает, и народ только фичи пилит?
Андрей: Playwright всего месяц как публичный проект, поэтому и issues создано немного. Кроме того, качество проекта действительно на высоте — благодаря очень сильной команде и опыту, полученному за время работы над Puppeteer.
Что касается пул-реквестов, то проект в активной фазе разработки. Над Playwright работают 6 человек, так что коммитов получается действительно много.
Владимир: Обычно смотришь на пул-реквесты в опенсорс-проектах, там 100500 issues и 1 пул-реквест на протяжении 10 лет. А тут смотришь, серьезные ребята.
Андрей: Да, мы серьезно относимся к тому, что делаем.
Комьюнити
Всеволод: Хотелось бы получить какой-нибудь совет для тех, кто захочет писать на Playwright. Что делать помимо каких-то tutorial-шагов на GitHub? Может быть, есть какие-то возможные дополнительные инструменты, которые могут пригодиться, чтобы ускорить написание своих тестов?
Андрей: Если вы пишете тесты и используете Jest — есть jest-playwright, который поможет вам быстро начать писать кроссбраузерные тесты. Если вы используете Karma, то есть karma-playwright-launcher.
Всеволод: Скажи, а как ты себя чувствуешь после написания уже второго публичного фреймворка для тестирования, который кажется довольно значимым для сообщества тестировщиков и разработчиков? Насколько тебе кажется, что ты причастен к большому сообществу, радуешься ли ты? И думаешь ли о третьем фреймворке?
Андрей: Я очень рад комьюнити и очень люблю общаться с ребятами — это просто супер. По большому счету для меня это главный источник вдохновения. Спасибо всем, кто тратил свое время и файлил баги.
Про третий фреймворк — ну нет! Хотелось бы закончить на Playwright. Если Puppeteer был в основном про Chrome, то Playwright в этом плане находится на нейтральной территории, и мы можем заниматься в равной степени всеми тремя браузерами — это здорово. Надеюсь, что Playwright сделает для кроссбраузерного тестирования то же, что Puppeteer сделал для популяризации headless-браузеров и веб-автоматизации.
И если сайты в результате будут работать лучше — это будет идеально.
Для тех, кто осилил текст до конца и способен еще прочитать статью про Playwright, то вам сюда. А кто уже понял, что хочет поговорить с Андреем лично — ждем вас 8-9 апреля в Санкт-Петербурге на конференции Heisenbug и/или 10-11 апреля на HolyJS.
Автор: vbrekelov
