Согласен, фиксиррованные таймауты - это хрупкие тесты.
Но что такое окончание загрузки? Что должен определить Селениум? Если загрузка динамическая, значит, ходят какие-то запросы от клиентского кода. Они для каждого приложения разные, где-то даже могут использоваться вебсокеты. Мы можем ожидать прохождения определенных запросов (хотя и это не 100% гарантия: после получения данных могут быть проблемы с производительностью скрипта, занимающегося отображением).
Отлавливать сами запросы через прокси - тоже плохое решение. Например, BrowserMob сильно тормозит работу сайта вообще.
Здесь всё слишком специфично. Непонятно, какой должен быть стандартный Wait. Например, я недавно работал с приложением, которое пуляет запросы раз в 2 секунды, и если пришли изменения, может неожиданно в любой момент работы закрыть сраницу лоадером. Где в нем окончание загрузки? Мы делали специфичные вейты, в которых детектировалось появление лоадера буквально при работе с любым элементом.
Я бы в данном случае использовал одно из двух:
- Ожидаем, что новое содержимое не подгружается в первую ячейку (если это применимо), например, в течение двух секунд. Плохо, что задержка. Плохо, что гарантия опять же неполная. В "чистом" случае время работы будет неотличимо от фиксированного вейта. Ускорение будет только для негативного случая. Хорошо только в плане культуры кода.
- Копаемся в клиентском коде и ищем, какие объекты должны быть инициализированы, какие статусы установлены и т.д. по окончании загрузки. И пробуем получить эти данные с помощью JavascriptExecutor. Либо с помощью него же навесить какое-то свое событие на обработчик данных с сервера. Плохо: не всегда это возможно, особенно если код подвергся обфускации и минимизации. Плохо: зависимость от реализации. Хорошо: когда компонент стабилен, это будет самое "умное" решение. В случае ошибки выполнения скрипта, можно фоллбэчиться на тот же таймаут.
