Идея для пулл реквеста в селениум биндинги:
Берем текущий имплисит вейт перед началом вейта (ведь теперь у нас есть getTimeouts() в последнем селениуме )
Устанавливаем его в 0
Делаем свои грязные явные ожидания
В файнали блоке - восстанавливаем имплисит вейт назад каким он был
…
профит
Подводные камни?
А зачем вообще нужен implicit wait, если мы будем постоянно работать с явными ожиданиями? Все равно он используется при findElement, который мы напрямую не будем дергать. Разве что кто-то все еще юзает стандартную фабрику и FindBy. Но опять-таки, в ней нет никакого смысла при использовании явных ожиданий.
А если будем? Всякое в жизни бывает. От прямого использования findElement все равно не получится отказаться. Тогда тут имплисит вейты и помогут
Почему же?
testomat.io управление авто тестами private WebElement waitFor(By locator, Function<By, ExpectedCondition<WebElement>> condition) {
return wait.until(condition.apply(locator));
}
Если все методы будут ходить через этот вейтер, то никакие findElement не нужны. Ну в идеале конечно можно сделать этот метод более generic, если нужно возвращать не только WebElement. Но это - тех. нюансы реализации уже.
Ох да. Ты прав. Забыл про эту фишку. Она ведь и в жс биндингах есть. Чего это я.
var button = driver.wait(until.elementLocated(By.id('foo')), 10000);
button.click();
Почему использовать стандартную фабрику и FindBy это плохо?
Поскольку она не спасет вас от популярных ошибок, возникающих при взаимодействии со сложными динамическими компонентами. Плюс ко всему, вы завязываетесь на выше упомянутый implicit wait, который будет учитываться при автоматическом поиске элементов. Вас, по сути, лишают контроля над поиском.
При этом, в отличие от By локаторов, с чистыми WebElement менее удобно работать в случае необходимости использования некоторых стандартных, а так же кастомных ExpectedConditions.
Ну и самым весомым аргументом должно быть заявление папы селениума о том, что этот механизм является самой большой его ошибкой, о которой он и по сей день жалеет. Придумывался он еще очень давно, требования были другие, тестируемые системы были легче и т.п. Сейчас это - пережиток прошлого. Явные ожидания - то, на чем следует акцентировать внимание.
Конечно, бывают исключения. И если вы тестируете статический сайт для домохозяек, то стандартные фабрики и ожидания вполне подойдут для такой задачи.
Завернут.
GET /wd/hub/session/:sessionId/timeouts
Саймон как бы не разу не папа селениума 
А заявление just for trolling.Самая большая их ошибка это StaleElementReferenceException.
т.е. вставлять вейты руками на каждый второй экшен? Или городить свою реализацию имплисит вейта?
Было бы любопытно взглянуть на UI Automation тулу без implicit wait - я такой не могу припомнить.
В каждой шутке есть доля шутки.
Не совсем понял, о чем речь. В случае вэба, уже лет 5 живу без implicit wait. И в рассказы о каком-то невероятном complexity при использовании явных ожиданий, или что без неявных не прожить никак, - не поверю. Если речь чисто о mobile - ok, shit happens.
Я не знаю на каком стеке и энвайроменте у вас прошли эти 5 лет - у меня минимум получалось 5 seconds implicit wait без ущерба стабильности. Опускать имплисит в ноль в монотонно расставлять разные вейты в разных местах для каждой платформы/клиента/версии из рана в ран - имхо скучно и глупо.
Тот самый момент, когда осознаешь, что Angular нужно обходить стороной. Но мне, видимо, не понять вашей боли. У нас сейчас все пишут на React. В прошлой конторе 3.5 года сидели на Backbone.
Но вейты я не расставляю в разных местах. Все это выносится в отдельное место. Да и 2х глобальных таймаутов (для коротких и длинных операций) оказывается вполне достаточно, как показывает практика. У каждого есть свои наработки. И не обязательно изобретать все с нуля для новых проектов.
Ничего не напоминает?
Не понял посыла. Мы уже начинаем сравнивать implicit и explicit wait таймауты? Или может вы надеялись услышать, что explicit wait будет работать вообще без таймаутов? Я вообще пока не совсем понимаю, что вы пытаетесь мне доказать сейчас. Что для удобной работы с неявными ожиданиями нужно писать свой велосипед? Так это и джуну понятно. Но я это сделал 1 раз, и пользуюсь на протяжении многих лет (с минимальным рефакторингом). В случае со стандартной фабрикой мне как бы тоже пришлось бы писать свои декораторы. И какой мне тогда профит от стандартной фабрики, которая даже с динамическими элементами не умеет работать?
2 и 3 пункты справедливы, соглашаюсь.
Но первый - вейт наоборот будет проходить быстрей, особенно для несуществующих элементов. Но вообще в плане HTTP запросов к драйверу - да, их станет больше тут вы тоже правы.
Ok, nevermind.
Быстрее чем что? Implicit wait - это доверительный интервал, которым вы готовы жертвовать, что бы окончательно убедиться в [присутствии|отсутствии] элемента.