Comments 13
Чем продиктована необходимость использовать Thread.Sleep в тестах на Selenium? Кажется что если отталкиваться от условного "нулевого" пользователя (который до этого не использовал ничего из перечисленного), то порог входа в Playwright будет гораздо ниже. Например, на Playwright не нужно писать обертки, управляющие ожиданиями, а также в нем удобнее работать с локаторами элементов.
Могу предположить, что это для того, чтобы дождаться появления некоторых элементов, которые могут прогрузиться спустя, например, 15 секунд, так как под ними тяжелый запрос к серверу и т.д. Но есть и более изящные способы, чем таймаут.
Поддержка await в коде, теперь нет необходимости писать Thread.Sleep, а значит ваши тесты станут меньше по объему, одна при этом сильно стабильнее, нежели чем это было раньше
Автор в курсе про driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
или
WebElement element = wait.until(ExpectedConditions.elementToBeClickable(By.id("someid")));
?
Грамматических ошибок намеренное количество
Спасибо за статью, но посмею возразить:
входной порог для Playwright НАМНОГО ниже. Никто не заставляет пользоваться асинхронностью
from playwright.sync_api import sync_playwright
=)
Дальше все пишется как обычно, но нет больше головняков с ожиданиями. Кода значительно меньше, а работает он быстрее.
Главная разница в том, что Selenium - это инструмент для автоматизации браузеров, а Playwright - фреймворк для тестирования, который покрывает все основные нужды, которые нужно дописывать самому, если ты пользуешься Selenium.
Я много работал с Selenium, но считаю, что будущее именно за Playwright.
Еще раз спасибо!
ждать заданный элемент до тех пор, пока он не отобразится на странице, а значит больше не придется по новой запускать тесты из-за не успевшей загрузится страницы или не правильно заданного интервала времени
То есть, если в приложении или бэкенде баг и какой-то элемент или страница не появится вовсе, то тест зависнет навечно? Это же проблема, а не достоинство.
Насчёт асинхронности не понял. Сплошные эвэйты делают код полностью синхронным, да это и понятно, ведь в браузере все появляется последовательно.
Далее, сам метод HomepageHasPlaywrightInTitleAndGetStartedLinkLinkingtoTheIntroPage() асинхронный, но кто его будет вызывать асинхронно? Сам фреймворк, запуская несколько таких тестов параллельно, в разных табах браузера или в разных копиях браузера? Но это давно можно сделать в Jenkins или TeamCity. Так где же выгода?
То есть, если в приложении или бэкенде баг и какой-то элемент или страница не появится вовсе, то тест зависнет навечно?
Предположу, что ожидания там всё-таки с таймаутом :)
Ага. Что легко реализуется в Selenium одним вызовом в начале сессии.
Ну, использовать слипы в тестах это вообще очень, очень плохая идея, какой бы инструмент не использовался. А если юзать не голый Selenium, а Selenide, то эта проблема отпадает, так как там ожидание определенного состояния элемента/загрузки страницы уже имеется в намного более упрощенном виде. Впрочем, если и этого мало, то никто не мешает использовать js, в Selenide это так же весьма просто. Playwright не использовала, полагаю, что у него есть свои преимущества, но не те, что описаны в статье.
Selenium, конечно, хорошо, но Selenide ещё лучше ?. ПВ не видел. Про слипы, могу добавить одно, если вам надо автоматизировать IE, то через некоторое время вы натыкаете их очень много.
Особенности национальной автоматизации