Так сложилось, что я на данный момент работаю автоматизатором тестирования, до недавнего момента моим основным стеком в работе был C# + Selenium 3, однако не так давно было принято решение о переходе на Playwright и в данной статье я решил рассказать о своем опыте перехода с Selenium на Playwright и о том с каким трудностями и подводными камнями я столкнулся во время данного перехода.

Пару слов о Playwright

Фреймворк для автоматизации тестирования Playwright был разработан компанией Microsoft. Первая версия была выпущена в 2020 году, однако уже на данный момент он пользуется достаточно большой популярностью и в интернете можно найти не мало информации об использовании и особенностях данного фреймворка. Секрет успеха на мой взгляд заключается в хорошем сочетаний относительной простоты в использовании для новичков и достаточно большого спектра возможностей и софременных фич которые придутся по нраву опытным автоматизаторам тестирования. Поэтому давайте вместе разберемся с тем почему нам стоит как минимум попробовать использовать playwright в своей работе.

Работа с Playwright

Для начала стоит оговорится, что хоть данный фреймворк и достаточно прост в использовании, все же предполагает наличие базовых навыков в автоматизации тестирования в чем несомненно уступает своему главному конкуренту Selenium, однако если у вас есть хотя-бы чуть-чуть опыта работы в сфере автоматизации, то вам не составит труда перейти на playwright.

Headless мод

Первое что бросается в глаза при первом запуске автотестов на playwright, это то что у него по умолчанию в настройках стоит параметр Headless = true, что может немного сбить с толку при первом использовании, однако данная проблема достаточно легко решается, достаточно всего-лишь в используемый вами .runsettings файл добавить строчку

<Headless>false</Headless>

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

Асинхронные тесты

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

[TestMethod]
    public async Task HomepageHasPlaywrightInTitleAndGetStartedLinkLinkingtoTheIntroPage()
    {
        await Page.GotoAsync("https://playwright.dev");

        // Expect a title "to contain" a substring.
        await Expect(Page).ToHaveTitleAsync(new Regex("Playwright"));

        // create a locator
        var getStarted = Page.GetByRole(AriaRole.Link, new() { Name = "Get started" });

        // Expect an attribute "to be strictly equal" to the value.
        await Expect(getStarted).ToHaveAttributeAsync("href", "/docs/intro");

        // Click the get started link.
        await getStarted.ClickAsync();

        // Expects the URL to contain intro.
        await Expect(Page).ToHaveURLAsync(new Regex(".*intro"));
    }

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

Отсутствие Thread.Sleep в коде

Playwright это современный фреймворк и как любой современный фреймворк, он уважает время человека который будет с ним работать, а соответственно не нуждается в такой рудиментарной вещи как Thread.sleep в вашем коде, вместо него он использует такое выражение как:

await Expect(Page).ToHaveTitleAsync(new Regex("Playwright"));

Ему нет нужды задавать определенный временной интервал, который блокирует всю работу кода, вместо этого он из коробки поддерживает возможность писать код который в реальном времени будет ожидать загрузки элементов и производить с ними заданные пользователем действия сразу после появления необходимого элемента на странице. Это несомненно позволит сократить время на прогон ваших автотестов, а сам код в свою очередь станет меньше по объему, а так же повысится его читаемость и легкость в поддержке.

Использование Expect вместо Assert

Данный фреймворк не использует ставший уже традиционным метод проверки полученных значений путем написания Assert...., вместо этого он предлагает свою альтернативу в виде метода Expect. В чем же отличия нового метода в сравнений со всем нам уже известным и знакомым Assert? Главное преимущество нового метода проверки значений заключается как раз в асинхронности , нам больше нет необходимости задавать временной интервал до истечения которого вся работа кода будет остановлена вне зависимости от того появился нужны нам элемент на странице или еще нет. Метод Expect используется в паре с инструкцией await и будет ждать заданный элемент до тех пор, пока он не отобразится на странице, а значит больше не придется по новой запускать тесты из-за не успевшей загрузится страницы или не правильно заданного интервала времени, всю работу по ожиданию элементов на странице playwright полностью берет на себя.

Selenium vs Playwright

Selenium это фреймворк по автоматизации тестирования, за долгие годы ставший индустриальным стандартом, так какие же есть плюсы и минусы в его использований?

Плюсы:

  • Несомненно это порог входа, который значительно ниже не только в сравнений с playwright, но и со всеми остальными фреймворками в данной области.

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

  • За долгие годы, накопилась обширная библиотека знаний в виде ответов на форумах, видео уроках, книгах, статьях и тд. Несомненно это является его большим плюсом, так-как пользователь столкнувшись с какой-то проблемой, сможет оперативно найти в интернете способы ее решения.

Минусы:

  • В последние годы Selenium развивается достаточно медленно, и постепенно перестает отвечать стандартам бурно развивающейся индустрий.

  • За долгие годы данный фрейморк достаточно сильно разросся в плане объема, из-за чего запуск тестов на нем становится все тяжелее, а сами тесты выполняются дольше чем у playwright.

Мы рассмотрели плюсы и минусы Selenium, теперь предлагаю перейти к playwright.

Плюсы

  • Несомненно самым важным плюсом playwright является поддержка асинхронности, это позволяет выполнятся коду быстрее, а так же это достаточно современный подход к написанию автотестов и за ним безусловно будущее

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

  • Поддержка await в коде, теперь нет необходимости писать Thread.Sleep, а значит ваши тесты станут меньше по объему, одна при этом сильно стабильнее, нежели чем это было раньше

  • У playwright достаточно быстро-растущее комьюнити, данный фреймворк на рынке всего 3 года, но за столь короткий срок уже успел обзавестить обширной фан-базой, а так же привлечь к себе внимание крупных игроков рынка IT

Минусы:

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

  • Несмотря на всю скорость своего развития, playwright пока что остается достаточно нишевым фреймворком и потеснить Selenium на поприще индустриального стандарта в ближайшие пару лет точно не сможет.

Итог

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

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


  1. gitcha
    10.10.2023 12:36

    Чем продиктована необходимость использовать Thread.Sleep в тестах на Selenium? Кажется что если отталкиваться от условного "нулевого" пользователя (который до этого не использовал ничего из перечисленного), то порог входа в Playwright будет гораздо ниже. Например, на Playwright не нужно писать обертки, управляющие ожиданиями, а также в нем удобнее работать с локаторами элементов.


    1. Vitimbo
      10.10.2023 12:36

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


      1. gitcha
        10.10.2023 12:36

        Все так, спасибо. Это был скорее риторический вопрос, чтобы автор задумался над своими выводами и рассмотрел проблему с другой стороны. В набросе в стиле "че за бред" как-будто нет смысла.


  1. Helwig
    10.10.2023 12:36
    +3

    Поддержка await в коде, теперь нет необходимости писать Thread.Sleep, а значит ваши тесты станут меньше по объему, одна при этом сильно стабильнее, нежели чем это было раньше

    Автор в курсе про driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
    или

    WebElement element = wait.until(ExpectedConditions.elementToBeClickable(By.id("someid")));

    ?


    1. egribanov
      10.10.2023 12:36

      Это бесконечная тема для обсуждения, на селениуме написано столько, что решить можно абсолютно любую проблему. Главный плюс плейрайта это скорее можно запускать хром, лису и сафари из коробки на любой ос. Появился chrome for test конечно уже, но все же


  1. SaintMihail
    10.10.2023 12:36
    +2

    Грамматических ошибок намеренное количество


  1. Cynic14
    10.10.2023 12:36

    Спасибо за статью, но посмею возразить:
    входной порог для Playwright НАМНОГО ниже. Никто не заставляет пользоваться асинхронностью

    from playwright.sync_api import sync_playwright

    =)

    Дальше все пишется как обычно, но нет больше головняков с ожиданиями. Кода значительно меньше, а работает он быстрее.

    Главная разница в том, что Selenium - это инструмент для автоматизации браузеров, а Playwright - фреймворк для тестирования, который покрывает все основные нужды, которые нужно дописывать самому, если ты пользуешься Selenium.

    Я много работал с Selenium, но считаю, что будущее именно за Playwright.

    Еще раз спасибо!


  1. dyadyaSerezha
    10.10.2023 12:36

    ждать заданный элемент до тех пор, пока он не отобразится на странице, а значит больше не придется по новой запускать тесты из-за не успевшей загрузится страницы или не правильно заданного интервала времени

    То есть, если в приложении или бэкенде баг и какой-то элемент или страница не появится вовсе, то тест зависнет навечно? Это же проблема, а не достоинство.

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

    Далее, сам метод HomepageHasPlaywrightInTitleAndGetStartedLinkLinkingtoTheIntroPage() асинхронный, но кто его будет вызывать асинхронно? Сам фреймворк, запуская несколько таких тестов параллельно, в разных табах браузера или в разных копиях браузера? Но это давно можно сделать в Jenkins или TeamCity. Так где же выгода?


    1. iBljad
      10.10.2023 12:36

      То есть, если в приложении или бэкенде баг и какой-то элемент или страница не появится вовсе, то тест зависнет навечно?

      Предположу, что ожидания там всё-таки с таймаутом :)


  1. Lutiiin
    10.10.2023 12:36

    Ну, использовать слипы в тестах это вообще очень, очень плохая идея, какой бы инструмент не использовался. А если юзать не голый Selenium, а Selenide, то эта проблема отпадает, так как там ожидание определенного состояния элемента/загрузки страницы уже имеется в намного более упрощенном виде. Впрочем, если и этого мало, то никто не мешает использовать js, в Selenide это так же весьма просто. Playwright не использовала, полагаю, что у него есть свои преимущества, но не те, что описаны в статье.