Поддерживаю

Принцип работы- определяется элемент, по которому (обычно по его присутствию) понятно загрузился виджет или ещё нет.  Затем при инициализации класс виджета включается ожидание этого элемента.

Иногда еще наследуют устраивая цепочки - типа виджет "новости" состоит из виджета "политика", виджета "спорт" и виджета "погоды".

И типа вызывая Новости, мы ждём загрузки виджета, который в свою очередь ждет загрузки трёх других.

Оверинжыниринг, как мы его любим и ценим.

Схожую идею можно реализовать в Селениде одной строкой в конструкторе типа:

$(novosti-header).shouldBe(visible);

не оверинжиниринг, а "альтернативная реализация"

просто в селениде есть своя, поэтому нет смысла (и даже вредно) смешивать

спасибо,
а как лучше реализовать след кейс:
на странице не загрузился ни один элемент (например ошибка при соединении с сервером), тесты будут падать один за другим не находя элементы
как лучше и грамотнее сделать так, чтоб если загрузки страницы не произошло - тесты гнать не надо?

ловить ответ от сервера и делать то, что вам нужно в случае 500х

Так а в чём проблема? Пусть тесты гонятся. Они упадут, ты увидишь в отчётах скриншоты и всё поймёшь.

ну а если они идут долго? получается время потрачено зря

если гоняешь в ночь, то это неважно. На утро пришла и отчет готов

а так есть способ через @BeforeClass сделать пробный запрос

если сервер не отвечает или возвращает ошибку какую, то скипать тесты

ну запрос имею в виду через какой Rest Assure послать

Лучше сделать отдельно health check job, которая только соединение проверяет. Тогда если она сломалась - результаты тестов игнориуем.

Всем привет!
Ребят, я тут немного подзавис: как проверить, что elements (list) не появился совсем?
Кейс:
Когда есть чаты, то и список elemnts я полдучаю по id = chatItemList.
А когда списка нет, то и elements тоже нет

Но канает - это же ElementsCollection

Вот на что студия ругается:
Type mismatch.
Required: CollectionCondition!
Found: Condition!

может  shouldHaveSize попробовать?