Ожидание элемента в selenide, возвращающее boolean

webdriver selenide
, , ,
#21

Делал для себя ожидалки - например тест что появится элемент но не известно через сколько 5-10-20 сек
которые возвращали булеан - которым можно фейлить тест в конце - время ожидания кастомное.

    public static boolean checkTextLoop(String displayedText, int loopLength){
        if ($(byText(displayedText)).exists() == false) {
            int count = 0;
            do {
                sleep(loopLength);
                refresh();
                count++;
                rootLogger.info(displayedText+" not detected, loop#: "+count);
                if ($(byText(displayedText)).exists() == true) {
                    rootLogger.info(displayedText+" is displayed");
                    return true;
                }
            } while (count < 5);
        rootLogger.info(displayedText+" NOT displayed");
        return false;
        }
        rootLogger.info(displayedText+" is displayed");
        return true;
    }

или так… ввобщем заворачиваем в ожидалку любой элемент или проперти:

 public static boolean checkPageTitle(String expectedTitle) {
        int i=0;
        while (i>20){
            getWebDriver().getTitle();
            sleep(1000);
            i++;
            if(getWebDriver().getTitle()!=null){break;}
        }
        if (expectedTitle.equals(getWebDriver().getTitle())==false){
            rootLogger.debug("false");
            return false;
        }
        rootLogger.debug("true");
        return true;
    }
#22

Спасибо

#23

Вся проблема в том, что в случае false (т.е. если элемент не появился) эта ожидалка будет гарантированно ждать максимально время. Это ведь ужасно долго! В этом смысле это плохое решение.

#24

Ну если у нас нет кроме времени условия другого ожидания…
Какой вариант? инплисити вейт и задаём сколько времени мы согласны потерять перед фейлом если на GUI не будет елемента.

Например из практики:
была проверка хуков емейлов

  • отправка письма
  • получение нотификашки
    критерий успеха если хук сработает за 30 сек то ок, если больше - фейл
#25

Это то самое, про что я говорю “взять тестовую среду под свой контроль”.
Если этого не сделать, то действительно, никаких других вариантов, кроме слипов, не остаётся, и проект скатывается ниже днища прямо в ад.

30 секунд - непозволительно много.

Я подробно рассказывал об этом на последнем SeleniumCamp: Arrange, mazafaka! (Andrei Solntsev, Estonia) [RU] - YouTube

2 лайка
#26

Отличное видео “Как закрыть поп-ап которого нет”
Ок моки, стабы, прокси - вопросов нет - функциональные тесты отдельных компонентов
“Нельзя использовать внешние сервисы” - ок

Но как без этого не понять всё ли работает в итоге для пользователя E2E а не в замоканой среде.
Понятно что стабильность таких тестов ниже но если тесты правильные - это == стабильности E2E всей системы.

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

Цель этих тестов не функциональное тестирование а работа всей ситемы.

Фотопик:
По поводу “проверки ветра и крыла, моделирования и бла-бла” -
комета-катастрофа-без-реальных-тестов
Вот зачем ральные тесты.

И таких тестов не должно быть много. Это может быть даже отдельный сьют с запуском по расписанию (монитор) а не по коммиту

#27

Да, эти вещи я в конце тоже говорил.

Если у вас правильная пирамида, есть куча юнит-тестов, есть куча UI-тестов с замоканными сервисами, и есть всего парочка тестов, которые ждут баннера 30 секунд - всё в порядке. Ждите.

Но что-то мне подсказывает, что вы и такого вопроса на форуме не задали бы.

1 лайк