Асинхронный вызов может

Третий вопрос: а критичный ли это функционал ("всплывает"), и надо ли его вообще покрывать UI-тестом?

разбиваем задачу на несколько: проверка что отображается корректная икнока для определенного типа задачи, что много задач выполняется успешно.
В первом случае 1 задача = 1 иконка
Во втором порядок их появления вообще не имеет никакого значения, как и их появление, но считаем, что если хоть одна появилась то и остальные появятся (класс эквивалентности такой или появится хоть одна, или не появятся вообще никакие)

Зачем мне воображать проверку того чего у меня нет? :)

Мне непонятен этот ответ. Я спрашивал "что проверяется?"
Вы отвечаете "асинхронный вызов может". Что может?

А если задач несколько и аякс вызов одной залип и не дал появиться другой? Блин, я так понимаю у многих беда с наличием интересных проэктов

смотря что считать интересным проектом

По-моему Вы понимаете неправильно, и дело скорее в том что у Вас частная задача с частным случаем которого у большинства нет, не нужно, и не будет нужно.

Именно отсутствием большой необходимости в таких задачах и объясняется отсутствие реализации или моего понимания "что это вообще за прогресс со всплывающими иконками"?

А кто из чатика тут:
Открытый Load Testing Community MeetUp в Райффайзенбанке??)))

по второй части, если  предложенные вами иконки это элементы (например img) с общим каким-то контейнером, то мы можем собирать все которые есть на странице и проверять что там содержаться те которые нам нужны по какому-то признаку

Или разрабы извращуги)

Запилить цикл по структуре данных списочного типа с элементами  "локатор : видимость"
плюс "условие выхода" (тоже может быть вида "локатор : видимость").

Проходим по списку. Если мы элемента ещё не видели, пытаемся его найти (в try-catch).

Проверяем условие выхода -- если оно тру, выходим, проверяем все ли элементы в списке были видимы.

Своя кастомная реализация своей кастомной проблемы. Не вижу зачем тут вообще к Селениду обращаться: основа фреймворка включать "каждой дырке затычку" не обязана.

Да ладно, народ, что вы набросились! Товарищ предлагает необычную проблему и необычное решение. Как минимум почва для размышлений. Может, через 10 лет только так и будем тестировать.

(крестится) Я совершенно далёк от "набросится", я рассказал по каким причинам этого нет, и даже решение предложил.

Поверьте, это не частная задача. Проблема в том что в Украину аутсорсятся в основном CRM, а в Европе сейчас на вебах интерфейсы пишутся на все что можно представить (чаще всего ИИ и интернет вещей с системами умного дома, ну и автопилоты для машин). Там столько всего, что и не в каждую десктоп аппликуху запихнешь.

И всё-таки, Artur , самый важный вопрос: откуда ваш тест знает, ЧТО надо проверять? Т.е. сколько должно появится тултипов и с какими текстами? (если они все такие динамические и могут появляться и исчезать в случайные моменты)

Я могу придумать несколько вариантов. Долго писать на мобиле но например процесс обработки я могу завернуть в какую-то обёртку (как Page Object паттерн только придумаю свой Process Object паттерн). И при одновременном запуске нескольких процессов  я бы сделал в тест сетапе ассинхроннный пул задач в каждой из которых проверялся бы нужный элемент. А в тиар дауне теста бы ждал завершения всех ачсинхронных задач.

0_0  Насколько я знаю из 12 лет работы в украинских ИТ проектах, аутсорсится 100500 проектов, без всяких "в основном".

Повидал я прогресс-баров, и если бы мне сказали "прогресс-бар с меняющимся текстом метки", -- это я знаю. А вот "со всплывающими иконками" -- это что-то новенькое.

В том то и дело, что в Украинском аутсорсе. В Украине мало своих собственных продуктовых проэктов, они в корне отличаются от того что аутсорсят