Надежное тестирование динамических UI-компонентов: стратегии работы с циклическими счетчиками

Асинхронность и жизненный цикл UI-элементов: почему стандартные ожидания Selenide не подходят для счетчиков

Вы пишете конструкцию onAdvertisingModulePage().counter().shouldHave(text("5"), ofSeconds(6));, запускаете тест и своими глазами видите, как на экране появляется цифра 5. Однако тест падает. В логах Selenide сообщает, что по истечении шести секунд фактическое значение элемента оказалось равным «4» или «2». Возникает парадокс: человек видит нужный текст, а автоматизированный скрипт, имея в запасе целых шесть секунд на поиск, умудряется его пропустить. Проблема кроется не в багах фреймворка, а в фундаментальном расхождении между тем, как мы воспринимаем непрерывное изменение интерфейса, и тем, как WebDriver взаимодействует с браузером.

Чтобы понять причину нестабильности тестов на динамических компонентах, необходимо разобрать два скрытых механизма: анатомию асинхронных ожиданий и жизненный цикл элементов в современных frontend-фреймворках.

Иллюзия непрерывного наблюдения

Человеческий глаз воспринимает интерфейс как непрерывный поток света. Когда счетчик меняет значения 5-4-3-2-1 каждую секунду, мы видим весь процесс от начала до конца. Из-за этого возникает ложное интуитивное представление о работе метода shouldHave. Кажется, что Selenide «смотрит» на экран в течение заданных шести секунд и ждет появления нужного текста.

В реальности автоматизация работает по принципу стробоскопа. Selenide не наблюдает за браузером непрерывно. Он использует механизм поллинга (от англ. polling — опрос).

Алгоритм стандартного ожидания выглядит так:

Запросить у браузера текущее состояние элемента.

Проверить, соответствует ли состояние ожидаемому (в нашем случае — равен ли текст «5»).

Если да — тест пройден, выполнение продолжается.

Если нет — уснуть на определенный интервал времени (по умолчанию в Selenide это 200 миллисекунд).

Проснуться и повторить цикл, пока не истечет общий таймаут (6 секунд).

!Сравнение частоты обновления UI и поллинга Selenide

Именно в фазе «уснуть» кроется первая уязвимость. Если нужная цифра появляется на экране ровно в тот момент, когда поток выполнения теста находится в состоянии Thread.sleep(), Selenide физически не может об этом узнать.

Однако сам по себе интервал в 200 миллисекунд кажется достаточно коротким. Если цифра «5» держится на экране целую секунду (1000 миллисекунд), Selenide должен успеть «проснуться» и проверить ее как минимум 4-5 раз за это время. Почему же тогда происходят пропуски? Здесь в игру вступает скрытая задержка архитектуры WebDriver.

Накладные расходы WebDriver и сетевая латентность

Команда counter().shouldHave(text("5")) не выполняется мгновенно. Архитектура взаимодействия между вашим Java-кодом и браузером многослойна.

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

Java-процесс формирует HTTP-запрос по стандарту W3C WebDriver.

Запрос отправляется по сети (или через loopback-интерфейс, если запуск локальный) к драйверу браузера (например, ChromeDriver).

ChromeDriver транслирует эту команду во внутренний протокол браузера (Chrome DevTools Protocol).

Движок браузера приостанавливает выполнение JavaScript, ищет элемент в DOM-дереве, извлекает его текст и формирует ответ.

Ответ проходит весь путь в обратном направлении до вашего Java-кода.

Время выполнения одного такого цикла мы назовем (время запроса). В идеальных локальных условиях может составлять 10–20 миллисекунд. Но при запуске в CI/CD пайплайнах, при использовании удаленных ферм (Selenoid, BrowserStack) или при высокой нагрузке на CPU машины, может непредсказуемо возрастать до 300, 500 и даже 800 миллисекунд.

Реальный интервал между проверками — это не просто время сна. Это время сна плюс время выполнения запроса: . Если из-за сетевой задержки или лагов браузера возрастает до 800 миллисекунд, фактический интервал между проверками становится равным 1 секунде. В такой ситуации тест может проверить интерфейс, когда там горит «6», уйти в долгий цикл запроса-ответа, и в следующий раз получить данные, когда счетчик уже переключился на «4». Цифра «5» проскальзывает между тактами опроса.

Жизненный цикл элемента: мутация против пересоздания

Вторая причина нестабильности кроется в том, как именно frontend-приложение обновляет счетчик на уровне DOM-дерева. Современные реактивные фреймворки (React, Vue, Angular) могут обновлять интерфейс двумя принципиально разными путями.

Первый путь: Мутация текстового узла (TextNode mutation). В этом случае сам HTML-тег (например, <div id="counter">) остается в памяти браузера неизменным. Фреймворк лишь меняет текстовое содержимое внутри него. Для Selenide это самый благоприятный сценарий. Драйвер один раз находит элемент по локатору, кеширует ссылку на него и при каждом такте поллинга просто запрашивает его свойство innerText. Это работает быстро и предсказуемо.

Второй путь: Пересоздание элемента (DOM Re-rendering). Очень часто при обновлении состояния компонента фреймворк полностью удаляет старый HTML-узел из DOM-дерева и вставляет на его место новый, точно такой же узел, но с новой цифрой. Визуально для пользователя ничего не меняется. Но для WebDriver это катастрофа.

!Изменение DOM-дерева при обновлении счетчика

Когда Selenide обращается к элементу, который был удален из DOM, WebDriver выбрасывает StaleElementReferenceException (исключение устаревшей ссылки на элемент). Это означает, что указатель в памяти браузера, по которому драйвер пытался прочитать текст, больше не существует.

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

Проблема в том, что обработка исключения и повторный поиск элемента по локатору — это чрезвычайно «дорогие» операции с точки зрения времени. Если счетчик пересоздается каждую секунду, Selenide может постоянно натыкаться на устаревшие ссылки. Время из-за постоянных повторных поисков лавинообразно возрастает. Тест тратит драгоценные миллисекунды не на чтение текста, а на попытки зацепиться за постоянно ускользающий из DOM-дерева элемент. В итоге, пока Selenide борется с исключениями, нужная цифра «5» появляется и исчезает.

Концептуальное ограничение Eventual Consistency

Описанные выше проблемы приводят нас к пониманию фундаментального ограничения стандартных инструментов ожидания. Методы вроде shouldHave или waitUntil в Selenide и чистом Selenium построены вокруг парадигмы Eventual Consistency (согласованность в конечном счете).

Эта парадигма предполагает, что интерфейс может находиться в нестабильном состоянии (загрузка, анимация появления), но в конечном итоге он придет к стабильному целевому состоянию и останется в нем. Классический пример — ожидание появления кнопки после отправки формы. Кнопка может появиться через 1, 3 или 5 секунд, но когда она появится, она никуда не исчезнет. Тест может проверять экран с любой задержкой; как только кнопка отрендерится, рано или поздно очередной такт поллинга ее зафиксирует.

Циклический таймер, отсчитывающий 5-4-3-2-1, ломает эту парадигму. Цифра «5» — это не конечное стабильное состояние. Это транзитное (переходное) состояние. Оно имеет жестко ограниченный срок жизни (ровно 1 секунду).

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

Ваш кастомный метод endureRun(), построенный на базе Awaitility (с параметрами вроде pollInterval(Duration.ofMillis(200))), — это шаг в правильном направлении. Библиотека Awaitility изначально создавалась для гибкого управления асинхронными процессами в Java и позволяет отвязаться от жестко зашитых механизмов поллинга WebDriver. Она дает возможность агрессивно опрашивать состояние системы, игнорируя стандартные задержки фреймворка тестирования UI.

Однако, просто заменить Selenide.shouldHave на Awaitility.await недостаточно. Если не учитывать сетевую латентность и пересоздание DOM-узлов, даже Awaitility будет пропускать нужные значения. Чтобы заставить метод endureRun() работать надежно как швейцарские часы, необходимо изменить стратегию извлечения данных из браузера, минимизировав количество HTTP-запросов и исключив влияние StaleElementReferenceException.

Осознание того, что целевое состояние UI является транзитным, а инструменты проверки подвержены скрытым временным задержкам, — это ключ к созданию стабильных тестов. Переход от парадигмы «подождать, пока элемент стабилизируется» к парадигме «поймать элемент в жестком временном окне» требует иных технических подходов, которые строятся на минимизации накладных расходов между тестовым скриптом и браузером.

Специфика тестирования высокочастотных обновлений интерфейса: проблема дискретизации и пропусков состояний

Тест ожидает появления цифры «5» в течение шести секунд, цикл счетчика занимает ровно пять секунд, но тест всё равно периодически падает по таймауту. Этот парадокс возникает из-за фундаментального когнитивного искажения: мы воспринимаем работу автотеста как непрерывную видеосъемку экрана, тогда как на самом деле тест делает серию редких фотографий в темной комнате с помощью стробоскопа. Если вспышка стробоскопа ни разу не совпадет с моментом, когда на счетчике горит нужная цифра, для теста этого события не произойдет, сколько бы секунд ни длилось ожидание.

Дискретизация наблюдения и слепые зоны

Интерфейс современного веб-приложения обновляется непрерывно. Браузер перерисовывает кадры с частотой 60 раз в секунду, а JavaScript-таймеры могут менять состояние DOM-дерева каждую миллисекунду. Однако автотест лишен возможности наблюдать за этими изменениями в реальном времени.

Процесс проверки состояния в UI-тестах всегда дискретен. Тест отправляет команду через WebDriver, ждет ответа от браузера, анализирует полученный снимок DOM, сравнивает его с ожидаемым результатом и, если условие не выполнено, засыпает на определенный интервал (poll interval).

Время, пока тест «спит» или ожидает прохождения сетевых пакетов, образует слепую зону. Если транзитное состояние интерфейса (например, появление цифры «5» на одну секунду) полностью помещается внутри этой слепой зоны, тест перейдет к следующей итерации, будучи абсолютно уверенным, что нужного состояния на странице не было.

!Интерактивный таймлайн рассинхронизации счетчика и поллинга

При тестировании статических форм или финальных состояний (Eventual Consistency) слепые зоны не имеют значения: кнопка, появившаяся на экране, никуда не исчезнет, и тест неизбежно обнаружит её на следующей итерации. Но при работе с циклическими высокочастотными обновлениями размер слепой зоны становится критическим фактором успеха.

Математика промаха: Теорема Котельникова в UI

В цифровой обработке сигналов существует фундаментальный закон — теорема Котельникова (в западной литературе — теорема Найквиста-Шеннона). Она гласит, что для точного восстановления аналогового сигнала без искажений частота его дискретизации должна быть как минимум в два раза выше максимальной частоты самого сигнала.

Этот же математический принцип применим к UI-тестированию транзитных состояний. Пусть — это время жизни искомого состояния на экране (в нашем случае цифра «5» горит ровно секунду). Пусть — это фактический интервал между двумя последовательными проверками в тесте.

Чтобы математически гарантировать, что тест не пропустит транзитное состояние, должно выполняться условие:

Если цифра горит секунду, фактический интервал между проверками не должен превышать секунды. Почему именно половина?

Представим пограничный сценарий. Если будет равен секунды, существует вероятность, что первая проверка произойдет за секунды до появления цифры «5» (тест увидит «1»), а следующая проверка — через секунды. В этот момент цифра «5» будет гореть на экране уже секунды. Тест успешно её зафиксирует. Но из-за нестабильности среды (сборка мусора в JVM, задержка сети) первая проверка может произойти за секунды до появления «5». Тогда тест проснется через секунды, когда цифра «5» горит уже секунды, а следующая проверка случится еще через секунды — то есть спустя секунды после того, как «5» сменится на «4». Состояние будет пропущено.

!Схема гарантированного попадания в окно состояния

Только интервал, равный или меньший половине времени жизни состояния, гарантирует, что как минимум одна точка проверки (вспышка стробоскопа) обязательно попадет внутрь временного окна , независимо от того, в какой момент начался цикл опроса.

Фазовый сдвиг и иллюзия синхронизации

Частая ошибка при настройке поллинга — попытка синхронизировать частоту опроса с частотой обновления UI. Инженер знает, что счетчик обновляется раз в секунду, и устанавливает интервал опроса ровно в секунду.

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

Хуже того, фактический никогда не равен заданному в коде времени сна. Фактический интервал складывается из трех компонентов:

Время выполнения команды поиска и чтения текста через WebDriver.

Сетевые задержки между тестовым фреймворком и браузером.

Заданный интервал сна (например, миллисекунд).

Если задать интервал сна в мс, а накладные расходы составят мс, фактический составит секунды. При времени жизни цифры в секунду тест начинает медленно «отставать» от интерфейса. Это порождает классический стробоскопический эффект: тесту кажется, что счетчик пропускает цифры или идет в другом направлении, хотя визуально в браузере всё работает корректно.

Анатомия падения: почему 6 секунд недостаточно

Разберем детально, как именно падает тест вида shouldHave(text("5"), ofSeconds(6)) на циклическом счетчике 5-4-3-2-1.

Допустим, тест запускается в момент, когда на экране только что загорелась цифра «4». Цикл обновления — ровно мс на каждую цифру. Стандартные ожидания Selenide имеют базовый интервал поллинга в мс, но под нагрузкой CI-сервера один цикл «запрос к браузеру + получение ответа» может занимать, например, мс. Итоговый составит мс.

Таймлайн катастрофы выглядит так:

0.0 сек: На экране появляется «4».

0.1 сек: Тест делает первый запрос. Видит «4». Засыпает.

0.7 сек: Тест делает второй запрос. Видит «4». Засыпает.

1.0 сек: На экране появляется «3».

1.3 сек: Тест делает третий запрос. Видит «3». Засыпает.

1.9 сек: Тест делает четвертый запрос. Видит «3». Засыпает.

2.0 сек: На экране появляется «2».

2.5 сек: Тест делает пятый запрос. Видит «2». Засыпает.

3.0 сек: На экране появляется «1».

3.1 сек: Тест делает шестой запрос. Видит «1». Засыпает.

3.7 сек: Тест делает седьмой запрос. Видит «1». Засыпает.

4.0 сек: На экране появляется «5» (наша цель).

4.3 сек: Тест просыпается, начинает отправлять запрос. В этот момент происходит микро-задержка в сети или сборка мусора в Java на мс. Запрос доходит до браузера только к отметке 4.6 сек.

4.6 сек: Браузер возвращает состояние DOM. Тест видит «5», но пока ответ летит обратно по сети, проходит еще мс.

4.8 сек: Фреймворк получает ответ, но из-за внутренней логики обработки (или если элемент успел перерисоваться и кинул StaleElement) решает сделать еще одну попытку. Тест засыпает.

5.0 сек: На экране появляется «4».

5.4 сек: Тест делает запрос. Видит «4». Цель упущена.

К отметке в секунд (момент срабатывания таймаута) на экране горит «3». Тест падает с ошибкой, сообщая, что ожидал «5», а по факту получил «3». Инженер смотрит на скриншот падения, видит там «3», знает, что цикл длится секунд, и делает ложный вывод: «Наверное, браузер тормозит и не успел дойти до пятерки за 6 секунд, нужно увеличить таймаут до 10».

Увеличение таймаута не решает проблему дискретизации. Оно лишь дает тесту больше шансов случайно попасть в нужную фазу на следующем витке цикла. Это превращает автотест в лотерею: он может пройти три раза подряд и упасть на четвертый исключительно из-за флуктуаций сетевых задержек.

Ограничения стандартных инструментов синхронизации

Высокочастотные обновления интерфейса вскрывают архитектурные ограничения стандартных инструментов UI-тестирования. Методы вроде shouldHave или waitUntil проектировались для работы с монотонными изменениями: элемент не существовал, а затем появился навсегда; кнопка была заблокирована, а затем стала активной.

В таких сценариях фреймворку выгодно делать паузы между проверками побольше (например, мс), чтобы не перегружать браузер лишними запросами. Если кнопка появилась на мс позже, тест просто найдет её на следующей итерации.

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

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

Практическое применение Awaitility и метода endureRun для надежной фиксации значений циклического счетчика

Конструкция onAdvertisingModulePage().counter().shouldHave(text("5"), ofSeconds(6)); выглядит абсолютно логичной с точки зрения синтаксиса, но в условиях высокочастотного обновления интерфейса она превращается в лотерею. Тест падает с вероятностью, зависящей исключительно от сетевых задержек и загруженности процессора в конкретный момент времени. Причина кроется в том, что стандартные инструменты ожидания не предназначены для охоты за транзитными состояниями — они проектировались для ожидания финальной, стабильной отрисовки элемента. Когда нам нужно гарантированно поймать цифру «5» в цикле 5-4-3-2-1, обновляющемся каждую секунду, требуется переход от пассивного ожидания к агрессивному, контролируемому поллингу.

Библиотека Awaitility предоставляет именно такой механизм. В отличие от встроенных ожиданий UI-фреймворков, она позволяет гранулярно настраивать частоту опроса, игнорируемые исключения и задержки перед первым запросом. Использование кастомного метода endureRun на базе Awaitility — это архитектурный паттерн, который изолирует сложную логику синхронизации от читаемого DSL ваших тестов.

Архитектура метода endureRun

Чтобы Awaitility корректно работал в связке с Selenide, метод endureRun должен выполнять роль умного прокси-сервера между утверждением (assertion) и драйвером браузера.

!Архитектура метода endureRun

Awaitility работает по принципу бесконечного цикла while, который прерывается либо при успешном выполнении переданного блока кода, либо по истечении общего таймаута. Однако, если внутри блока кода выбрасывается исключение, Awaitility по умолчанию прерывает выполнение и пробрасывает ошибку наверх. В контексте UI-тестирования это фатально: в моменты обновления счетчика элемент может на долю секунды исчезать из DOM, вызывая ElementNotFound или UIAssertionError.

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

Разберем критические компоненты этой конфигурации:

atMost(Duration.ofSeconds(6)) — жесткий верхний предел. Если счетчик сломался и завис на цифре «4», тест не будет выполняться бесконечно.

pollInterval(Duration.ofMillis(200)) — частота ударов нашего «молотка». При времени жизни цифры на экране с, интервал мс гарантирует, что мы сделаем минимум попыток прочитать значение, пока оно отображается.

ignoreExceptionsInstanceOf(...) — щит от нестабильности DOM. Если в момент опроса Selenide попытается прочитать текст, а счетчик в эту миллисекунду перерисовывается, выброшенное исключение будет проглочено, и Awaitility просто перейдет к следующей итерации через мс.

untilAsserted(...) — терминальная операция. Она принимает Runnable (кусок кода, который ничего не возвращает, но может упасть с ошибкой). Если код внутри выполнился без ошибок (то есть Selenide нашел нужный текст), Awaitility немедленно завершает работу и тест идет дальше.

Проблема раннего связывания (Early Binding)

Перенос падающего теста внутрь endureRun требует понимания того, как Selenide ищет элементы. Частая ошибка при рефакторинге выглядит так:

Если компонент счетчика реализован во фронтенде так, что при смене цифры старый HTML-узел удаляется, а новый создается (типичное поведение для некоторых виджетов на React или Vue), переменная counter будет хранить ссылку на уничтоженный узел. Awaitility будет добросовестно делать запросы каждые мс, но все они будут лететь в «мертвый» элемент.

Правильный подход требует позднего связывания (Late Binding): поиск элемента должен происходить внутри лямбда-выражения, на каждой итерации поллинга.

В этом случае каждые мс метод counter() будет заново опрашивать DOM-дерево. Даже если узел был пересоздан, Selenide найдет его актуальную версию, прочитает текст и сверит его с ожидаемым.

Динамика перехвата транзитного состояния

Рассмотрим, как физически выполняется исправленный код. Допустим, мы запустили тест в момент, когда на счетчике горит цифра «2». Нам нужно дождаться полного цикла (1, затем снова 5).

!Динамика захвата состояния через Awaitility

с: Awaitility запускает лямбду. Selenide находит счетчик, видит текст «2», ожидает «5». Выбрасывается UIAssertionError. Awaitility перехватывает его (благодаря ignoreExceptionsInstanceOf) и планирует следующий запуск.

с, с, с...: Процесс повторяется. Тест непрерывно «бомбардирует» интерфейс легковесными запросами.

с: Интерфейс обновляется до «1». Очередной запрос видит «1», падает, Awaitility ждет дальше.

с: Интерфейс обновляется до «5».

с (ближайший такт поллинга): Awaitility запускает лямбду. Selenide запрашивает текст, получает «5». Утверждение shouldHave(text("5")) выполняется успешно (ошибок нет).

Awaitility фиксирует успех, прерывает цикл ожидания и передает управление следующей строке теста. Общее время ожидания составило секунды из разрешенных .

Именно агрессивный, независимый от внутренних таймаутов Selenide поллинг позволяет «вклиниться» в окно существования нужного состояния.

Конфликт таймаутов: Selenide vs Awaitility

При интеграции endureRun возникает скрытая архитектурная проблема — наложение таймаутов. По умолчанию shouldHave в Selenide имеет собственный таймаут (обычно секунды).

Если мы пишем endureRun(() -> element.shouldHave(text("5"))), происходит следующее: На первой итерации Awaitility запускает лямбду. Selenide видит, что текста «5» нет, и начинает ждать свои собственные 4 секунды, блокируя поток. Awaitility в это время заморожен, так как лямбда еще не вернула результат. Только через секунды Selenide выбросит ошибку, Awaitility её поймает, подождет мс и запустит вторую итерацию.

Вместо быстрых проверок каждые мс мы получаем медленные проверки раз в секунды. Это полностью уничтожает смысл использования Awaitility для высокочастотных обновлений.

Чтобы endureRun работал как скальпель, проверки внутри него должны быть мгновенными (Zero-Timeout Assertions). В Selenide это достигается передачей нулевого таймаута непосредственно в проверку:

Теперь shouldHave не ждет ни миллисекунды. Он делает ровно один срез DOM-дерева. Если текста нет — мгновенно падает. Это возвращает управление Awaitility, который отсчитывает свои мс и запускает следующий мгновенный срез. Мы возвращаем контроль над частотой дискретизации.

Оптимизация нагрузки: использование pollDelay

Агрессивный поллинг каждые мс создает определенную нагрузку на WebDriver и браузер. Если логика приложения такова, что мы точно знаем: после определенного действия счетчик начнет отсчет с 5, но само появление счетчика занимает время, мы можем оптимизировать endureRun.

Awaitility предоставляет метод pollDelay, который задает начальную паузу перед первой проверкой.

Если мы нажали кнопку «Запустить рекламу», и знаем, что анимация загрузки модуля идет ровно секунды, нет смысла бомбардировать DOM запросами в это время. pollDelay позволяет тесту «уснуть», экономя ресурсы CPU и снижая шум в логах WebDriver, а затем проснуться и начать частый опрос ровно тогда, когда вероятность появления нужного состояния максимальна.

Альтернативный синтаксис: Callable вместо Runnable

Метод untilAsserted, принимающий Runnable (код с проверками, выбрасывающими исключения) — это самый естественный способ интеграции с Selenide, так как мы продолжаем использовать привычные методы shouldHave или shouldBe.

Однако Awaitility поддерживает и другой подход — через Callable<Boolean>. В этом случае мы не используем ассерты внутри цикла, а возвращаем логическое значение:

Этот подход кажется более лаконичным, но имеет серьезный недостаток в контексте UI-тестов. Если в момент вызова getText() элемент исчезнет, WebDriver выбросит StaleElementReferenceException. Так как мы не используем ignoreExceptions, Awaitility немедленно прервет тест с ошибкой. Кроме того, при падении по таймауту отчет об ошибке будет неинформативным (просто ConditionTimeoutException), в то время как подход с untilAsserted и Selenide-проверками приложит к отчету скриншот и исходный код страницы в момент последней неудачной попытки.

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