С новым годом!

Мы зарелизили Selenide 6.2.0.

Давайте посмотрим, что нам приготовил первый релиз в новом году.

Наливайте чай и погнали!

Добавили ссылку “<Click to see difference>” для большинства селенидовских ошибок

Как вы помните, в Selenide 5.25.0 мы добавили поддержку OpenTest4J, в результате чего у селенидовских ошибок в IDE появилась ссылочка “<Click to see difference>”, позволяющая удобно посмотреть различия между ожидаемым и актуальным значением.

Но тогда мы всё порефакторить не успели, и ссылочка появилась не у всех типов ошибок.
А теперь должна появиться у всех.

См. issue 1589 и PR 1676.

Заменили $$.iterator() на $$.asDynamicIterable() и $$.asFixedIterable()

Ух какую старую болячку мы исправили! Ну молодцы же!

Есть в селениде метод $$ для коллекции элементов. Возвращает он объект класса ElementsCollection.
Изначально у него должен был быть только один метод $$.shouldHave(<условие>). Хочешь проверить коллекцию элементов на соответствие какому-то условию - передай нужное условие. Не нашёл готового условия - напиши своё, благо это легко.

The ошибка

Но в те давние времена случилось так, что я наследовал класс ElementsCollection от AbstractList<SelenideElement>. Об этом решении я неоднократно жалел впоследствии.

Что же случилось, спросите вы? А случилось то, что люди начали абьюзить коллекции как не в себя.

• Например, начали итерировать все элементы в коллекции (это случайно стало возможным благодаря наследованию от AbstractList).
• И ещё люди ожидают, что элементы в коллекции будут постоянно обновляться, ведь до сих пор селенид автоматически обновлял любые веб-элементы.
• Помимо сомнительного тест-дизайна, это вызвало ещё и проблемы с производительностью, ведь на каждом шаге итерации селенид должен загрузить заново всю коллекцию элементов. А это может быть медленно, особенно есть элементов много или коллекция фильтруется: $$("div").filter(visible).filterBy(text("Hello")).

The дилемма

Получилась дилемма:

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

Какой вариант ни выберешь - всем не угодишь.

The решение

И наконец мы придумали, как решить эту дилемму. Случайно унаследованные от AbstractList методы типа $$.iterator() мы пометили как @Deprecated. Вместо них предлагаем вам два метода, из которых вы сами сможете выбрать согласно вашим потребностям:

• $$.asDynamicIterable() - перегружает элементы коллекции при итерировании. Может быть медленным на больших коллекциях.
• $$.asFixedIterable() - не перегружает элементы при итерировании. Он быстрее, но не получает обновлений, если элементы удаляются или добавляются во время итерирования.

The совет

Какой из них я вам советую?

НИКАКОЙ! :)

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

Вместо итерирования всегда лучше написать свой CollectionCondition. Благо это легко.

См. issue 797 и PR 1688.

Исправили SoftAssert, чтобы он не валил тест

в довольно редкой ситуации:

1. если софт ассерт listener/rule/extension добавлен к тесту, но
2. софт ассерты выключены, и
3. внутри теста кидается и тут же ловится ошибка (try/catch).

Вообще в такой ситуации надо исправлять сам тест. :(

И всё же. До сих пор селенидовский софт ассерт валил тест, потому что в ходе теста была ошибка, и листенер это заметил. А теперь листенер стал чуть умнее и тест не валит.

Уф, ну и проблемки вы иногда подкидываете, дорогие пользователи… :)

См. issue 1646 и PR 1680.

Исправили софт ассерты, чтобы они включали все падения

Ещё одна редкая проблема с софт ассертами. Представьте ситуацию:

1. Софт ассерты включены;
2. В ходе теста случились какие-то селенидовские ошибки (пойманы софт ассерт листенером);
3. А также в ходе теста случилась какая-то другая ошибка (банальный NPE или assertEquals(2, 3)).

В этом случае селенидовский софт ассерт листенер валил тест (что правильно), но показывал только селенидовские ошибки (п. 2) и терял “другую” ошибку (п.3).

Теперь листенер стал умнее, и показывает все ошибки.

См. issue 1661 и PR 1679.

Добавили локаторы к некоторым селенидовским ошибкам

Мелочь, но стоит упомянуть.

Мы добавили селектор к некоторым селенидовским ошибкам.
Например, там, где селенид раньше кидал такую ошибку:

“Invalid element state: Cannot change invisible element”

Теперь он будет кидать такую:

“Invalid element state [.btn.btn-primary]: Cannot change invisible element”

Обновили BrowserUpProxy с 2.1.2 на 2.1.3

Важно отметить, что версия 2.1.3 - это форк оригинального BrowserUpProxy. Автор объявил о прекращении поддержки, добровольцы переняли инициативу и зарелизили версию 2.1.3 из форка.

Будем следить за ситуацией. В идеале хорошо бы перейти с BrowserUpProxy на mitmproxy. Есть добровольцы?

См. PR 1678.

Обновили TestNG с 7.4.0 на 7.5

Список изменений внушительный.

См. PR 1682.

С Новым Годом, друзья!
Стабильных тестов вам и красивых отчётиков!

Андрей Солнцев

ru.selenide.org

10.01.22