25 February

«Если сайты будут работать лучше — это будет идеально»: интервью с разработчиком Playwright Андреем Лушниковым

JUG Ru Group corporate blogWebsite developmentIT systems testingJavaScriptWeb services testing
Совсем недавно вышла статья про новый инструмент Playwright, одним из авторов которого является Андрей Лушников. Нам выпала возможность пообщаться с Андреем и задать все вопросы, которые внимательные читатели написали в комментариях. Думаю, в этом лонгриде они смогут найти ответы. Немного спойлеров:

  • Андрей рассказал историю развития Playwright и Puppeteer;
  • ответил на вопросы про протоколы, которые используют для работы с браузерами;
  • рассказал про сложности браузерных движков и планируемые интеграции Playwright.



Андрей Лушников приедет на конференцию 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, то вам сюда. А кто уже понял, что хочет поговорить с Андреем лично — ждем вас в Санкт-Петербурге на конференции Heisenbug и/или на HolyJS.
Tags:heisenbugheisenbug2020piterheisenbug2020playwrightheisenbug playwrightheisenbug testing
Hubs: JUG Ru Group corporate blog Website development IT systems testing JavaScript Web services testing
+25
4.4k 19
Comments 2