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

    Совсем недавно вышла статья про новый инструмент 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.
    JUG Ru Group
    Конференции для программистов и сочувствующих. 18+

    Similar posts

    Comments 2

      0

      Если кому-то интересно, есть ли в Playwright общие исходники с Puppeteer, то можно посмотреть на эти два файла, например:



      Отличаются только копирайтами

        +1

        Большое спасибо за интервью и за вопрос про Juggler в частности.
        Честно говоря, не очень понятно, как команда позиционирует Juggler. С одной стороны, насколько я понял из интервью, Juggler — это протокол именно для FF, который только идеологически связан с CDP, т.е. решает схожие задачи, но не обязательно схожим образом, поскольку некоторая часть протокола очень тесно связана с самим Chrome'ом и фактически не может быть кроссбраузерной.
        С другой стороны, Juggler похож на CDP, и Андрей упомянул, что они работают над долгосрочным API. Будет ли это API поверх CDP/Juggler, или Juggler и будет основой для данного API? Будет ли оно кроссбраузерным?


        Мне кажется, это важный вопрос для будущих инструментов. Например, если кто-то захочет создать библиотеку на Python, в каком направлении ему следует двигаться?


        1. Библиотека реализует общие методы, которые под капотом используют CDP/Juggler в зависимости от браузера.
        2. Библиотека реализует клиента для кроссбраузерного API.
        3. Библиотека коммуницирует с playwright, запущенным на node js.

        По поводу недоверия к пропатченным браузерам: на мой взгляд, проблема не столько в боязни за Rendering Engine. Представьте, что у нас есть веб приложение, и пользователи завели баг для определённой версии браузера (например, баг воспроизводится в FF версии < 70). В итоге мы создаём тест для регресса и гоняем автотесты и для новой версии FF, и для старой. Поскольку, насколько я это понимаю, определённая версия Playwright'а использует свою фиксированную версию браузера, мне, как автоматизатору, теперь необходимо придумать, как прикрутить использование нескольких версий Playwright'а в автотестах: возможно, всё решается разными контейнерами или виртуальными машинами для каждой версии, но, опять же, инфраструктурные затраты несравнимо больше, чем запуск разных версий с одной машины. Не стоит ещё забывать, что в данном случае мы ещё надеемся, что наши тесты совместимы с обеими версиями Playwright'а, особенно если протокол не менялся между версиями.
        С другой стороны, проблемы разделения Playwright и браузеров тоже понятны: наверняка, у всех была ситуация, когда при работе с selenium'ом возникала проблема совместимости вебдрайвера с соответствующим браузером из-за различия в версиях.


        Желаю удачи и успеха команде и проекту Playwright. Хочется верить, что это будущее автоматизации веб тестирования.

        Only users with full accounts can post comments. Log in, please.