Как стать автором
Обновить

Комментарии 10

Чем хорош Puppeteer? Он запускает headless-браузер и использует DevTools протокол, поэтому тесты проходят быстрее и стабильнее по сравнению с Selenium, а писать их можно на приятном JavaScript.


Селениум тоже может работать без башки, а писать тесты, имхо, гораздо приятнее на Питоне.

Зайти на страничку и сделать скриншот это, конечно, здорово, но как на счет работы с базами данных, с файловой системой, с архивами и т.п? Сквозные тесты по определению не отличаются особой стабильностью, на чем их не пиши, и я, откровенно говоря, удивлен тому, с каким рвением создаются все эти новые инструменты для них. Тем более, что Селениум всё ещё весьма торт.

В любом случае, спасибо за статью. Придется наблюдать за очередным творением :)
Каждый любит на разном писать тесты. Мне, например, больше нравится на Java/Kotlin. Но, думаю, что кто-то любит JavaScript/TypeScript, особенно в случае, когда можно использовать один язык для тестов и для написания UI.

С базами данных, файловой системы – определенно нужно работать на другом уровне.
Спасибо!
Судя по всему Playwright собираются портировать на .NET.
Поэтому будут шансы писать не только на JavaScript/TypeScript.

Мне тоже было интересно, чем Playwright отличается от других инструментов. Я поизучал вопрос, и теперь мне кажется, что достижение команды разработчиков Playwright намного больше, чем новая библиотека на node js для UI автотестов.
CDP (Chrome DevTools protocol) находится "ближе" к хрому, чем Selenium, поэтому он предоставляет больше информации и возможностей в работе с браузером. Проблема в том, что протокол был сделан для хрома, а тестировать веб приложения хочется в том числе и в ФФ. И огромная заслуга команды Puppeteer и Playwright в том, что они фактически провоцируют объединение и стандартизацию данного (подобного?) протокола для браузеров. Вот, например, тикет с обсуждением https://bugzilla.mozilla.org/show_bug.cgi?id=1512337
Стоит отметить и отношение Mozilla к этому вопросу (из https://bugzilla.mozilla.org/show_bug.cgi?id=1512337#c10):


Not supporting Puppeteer also poses significant web interoperability
risk to Mozilla. As websites migrate automation to Puppeteer, the
lack of cross-browser support in many cases leaves Firefox untested,
forcing Firefox to play a catch-up game addressing web compatibility
issues.
Simultenously Mozilla’s ambitions stretch beyond Puppeteer’s feature
set. Puppeteer is backed by the Chrome DevTools Protocol (CDP), which
also drives an armada of other tools. The simlarities between the
Juggler protocol presented in this patch and CDP are uncanny, and we
believe that it is in the best interest of the open web for us to
instead implement the subsets of CDP that allows us to support the
Puppeteer API surface.

Насколько я понимаю, Mozilla активно работает над remote protocol'ом (https://firefox-source-docs.mozilla.org/remote/index.html), который будет близок к CDP, что не может не радовать.


Playwright использует свой протокол для ФФ (Juggler), который, если я не ошибаюсь, похож на CDP, но тем не менее отличается от него и, соответственно, от remote protocol, который официально будет поддерживать Mozilla. С чисто прагматической точки зрения, использование Playwright сейчас для ФФ выглядит достаточно рискованно: кажется сомнительным, что браузер будет поддерживать и remote protocol, и juggler, поэтому можно ожидать, что и протокол, и внутренности playwright будут меняться (см. также https://wiki.mozilla.org/Remote/Meetings/2020/01/24#Minutes). Скорее всего, этот процесс не обойдётся без интеграционных проблем.


Резюмируя, хочется сказать огромное спасибо команде разработчиков. Благодаря их работе в области CDP-подобного протокола, мы можем ожидать, что появятся библиотеки и на других языках, что сильно облегчит многие задачи автоматизации тестирования.
Было бы ещё интересно узнать от самих разработчиков детали Juggler (https://github.com/puppeteer/juggler ?), его отличия от CDP и планы развития.

vbrekelov Спасибо за статью!
Хочу заметить, что первый пример кода на Playwright не работает, пробовал у себя запустить (и тот, где вы рассказываете про поддержку webkit и devices).
Проблема в том, что метод newPage() не имеет параметров, а переход на другую страницу (как сказано в ридмихе самого инструмента на гитхабе) осуществляется посредством

const page = await context.newPage();
await page.goto('https://habr.com/');


а не
const page = await context.newPage('http://habr.com/');
Верно, теперь это не работает =).
В версии 0.10.0 работало.
Можно посмотреть на изменения в документации:
github.com/microsoft/playwright/commit/2dd11eaa094b4a8fba94dd23a0466bf32da4a1a3#diff-04c6e90faac2675aa89e2176d2eec7d8

Но все примеры я поправил на GitHub, спасибо!
Честно говоря, не очень понял, чем Playwright отличается от cypress — не решают ли они очень похожие задачи? Буду рад любым замечаниям. Сейчас решаю для себя, какой подход применить в проекте.

Cypress – исполняет код тестов в контексте страницы, манипулируя интерфейсом через DOM API. Такие тесты не совсем интеграционные, больше похоже на Karma.


Playwright (равно как и Puppeteer, и Selenium) управляют браузером через специальный протокол, код ваших тестов строго отделен от кода на тестируемой страницы.

Где человеку, разрабатывающему на Java и Selenium, можно посмотреть пример настройки CI для PlayWright на TeamCity или Jenkins?
В документации PLayWright нашел только GitHub Actions.
Действительно про TeamCity или Jenkins в документации пока ничего нет.
Но появилась отдельная страница про CI: playwright.dev/#version=v1.3.0&path=docs%2Fci.md&q=ci-configurations
Там можно найти варианты конфигураций не только для GitHub Actions
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.