Pull to refresh

Comments 4

Хорошая статья, однако из собственного опыта есть несколько моментов:
1) На практике оказывается, что для начинающих, не имеющих особого опыта с jQuery, все-таки понятнее By локаторы, и чем дельше, тем меньше людей, который знают jQuery
2) Если проект предполагается к использованию в основном на Windows, то бывают определенные трудности с отображением шрифтов в Linux-контейнерах точно так же, как это будут видеть пользователи на Windows. Очень скользкий момент.
3) Иногда требуется более гибко манипулировать таймаутами при поиске элементов, поскольку бывает необходимо ускорить выполнение тестов.
Есть, собственно, вопрос по этому поводу. Если мы хотим получить количество элементов с определенным локатором, или список этих элементов, сколько времени это займет с использованием Selenide? Подозреваю, что таймауты можно перегружать, но как-то не бросилось подобное в глаза при чтении статьи.
4) JUnit какой версии имеется ввиду? 4? А можно ли немного примеров с JUnit 5 + Gradle? Там, например, есть отличия в плане параллельного выполнения и lifecycle, поэтому некоторые вещи, такие как создание скриншота (да и архитектура тестового фреймворка), будут заметно отличаться местами. Взять хотя бы доступ к свойствам экземпляра тестового класса из расширений.
В целом статья понравилась, но дьявол, как обычно, кроется в деталях. Опять же, из собственного опыта, комбинация maven + TestNG показывает самый лучший результат по времени при параллельном выполнении на 4-5 разных браузерах.

1. Так JQuery тут не при чём. Вещи типа `#id` и `.class` — это обычные CSS селекторы. Они были до JQuery и будут после JQuery. Миллионы людей используют их в Chrome developer tools при разработке и отладке без всяких JQuery.
3. Список элементов по селектору можно получить вот так: `$$(".class")`. Скорость этой операции никак не зависит от таймаутов. Она зависит только от количества элементов (ну и тормознутости браузера).
И да, таймаут легко задать свой: `Configuration.timeout = 8000`
4. Для JUnit5 тоже есть поддержка: selenide.org/javadoc/current/com/codeborne/selenide/junit5/package-summary.html

Тут есть разные мнения, но точно скажу, что JUnit как минимум не хуже, чем TestNG, умеет запускать тесты параллельно. Время запуска тестов гораздо больше зависит от самих тестов и AUT, чем от тестового фреймворка.
1. JQuery тут при этом — "$(...)" и "$$(...)", я не про CSS селекторы говорил.
3. Я знаю, и эта операция зависит от дефолтных таймаутов. implicitlyWait, например.
4. Вот за это спасибо

Я говорил про связку maven + TestNG, а не про голый TestNG/JUnit. Замените maven на Gradle, и результат может оказаться отличным. Да, они оба (все три, если рассматривать JUnit 4 и 5 версии как два разных) умеют запускать тесты в параллель, но делают это по-разному. Мне субъективно больше нравится как это сделано в TestNG, хотя это дело вкуса, наверное.
3) Если общий таймаут поменять, то уже ответили. Также есть возможность поменять для отдельной проверки время ожидания использовав waitUntil(Condition, milliseconds) или waitWhile(Condition, milliseconds) вместо should… методов. Здесь подробнее можно selenide.gitbooks.io/user-guide/content/ru/selenide-api/selenide-element.html
Sign up to leave a comment.

Articles