Selenium WebDriver waiters (explicit/implicit) and Protractor

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Речь пойдёт о насущной для всех юайных тестов проблеме — подождать. Примеры и особенности будут рассматриваться для протрактора (JS), но суть вейтеров и слипов едина для всех реализаций вебдрайвера, поэтому всем, у кого есть вопросы или недопонимание, будет интересно. В конце ссылка на мою реализацию явного ожидания для протрактора. Это функция, которая:
1. чейнит элемент
2. принимает аргументом время явного ожидания
3. сетит неявное ожидание в ноль
4. ждёт время, переданное аргументом
5. сетит неявное ожидание обратно в дефолтное значение
6. возвращает тот же элемент, т.е. её можно чейнить. Выглядит примерно так:

field.waiReady(5000).click();

Первое, что нужно отчётливо понимать и помнить: слип — не вейтер!
Что такое sleep: browser.sleep(time) — это прерывание выполнения скрипта, т.е. потеря времени в чистом виде. Это просто недопустимо ни под каким предлогом. Почему? Есть 3 главные причины:
1. Действие выполнилось быстрее, остальное время в мусор.
2. Действию понадобилось больше времени и тест вылетел.
3. Я поставлю 1 слип, ведь так быстрее и проще. Здесь же не навредит... Я даже оберну его в метод и назову его... stabilizationTimeout(time)! После чего сработает правило разбитого окна и слипы со стабилизационными таймаутами заполонят нашу жизнь. Печаль-беда.

Что такое waiter: по своей сути вейтер — это поллинг. Ему параметром передаётся максимальное время ожидания. Т.е. если элемент уже готов, то он не будет ждать, а сразу начнёт работать. Если элемент не в порядке, то вейтер будет пытаться с ним взаимодействовать пока не кончится время, переданное параметром.
Вейтеров бывает 2 типа — explicit (явное ожидание) и implicit (неявное ожидание). Разница между ними в том, что implicitWait выставляется один раз и отрабатывает перед каждым действием, а explicit нужно писать руками и явно указывать сколько времени и на какое действие можно потратить.

Как нужно использовать Implicit waiter: он задаётся единым для всех тестов:

browser.manage().timeouts().implicitlyWait(2000);
время ожидания должно быть небольшим, иначе, когда мы захотим проверить, что элемента нет на странице, то будем ждать время неявного ожидания впустую.
В случае протрактора нужно учитывать, что он начинает работать только после того, как на странице отработает весь ангуляр (в случае дефолтного browser.ignoreSyncronization=false;). Также в протракторе реализован lazy search, это значит, что реальный поиск элементов в ДОМе начнётся только после выполнения над элементом действия:
let field = element(by.id(‘field’)); // здесь ничего не происходит
field.click(); // здесь протрактор ищет элемент на странице и кликает по нему

Пример explicit waiter-a на js:

browser.wait(() => field.isPresent(), 5000, ‘Field not found’);
browser.wait() принимает 3 аргумента — функция для поллинга, максимальное время ожидания и третий опциональный аргумент — текст ошибки. Здесь возникает вопрос:

Как работают implicit и explicit вейты вместе:
Работают они в параллели. У них обоих есть таймеры, которые стартуют одновременно и тут зарыта собака. Есть 3 возможных варианта: явное больше неявного, неявное больше явного и 2 таймера равны. Если элемент на странице есть и он хороший, то вне зависимости от вейтера всё случится быстро. Так что мы будем рассматривать вариант, когда всё плохо.
1. Implicit = 3000
Explicit = 3000
Когда таймеры равны, то всё просто и очевидно — мы будем ждать 3 секунды.
2. Implicit = 4000
Explicit = 3000
Таймеры стартанули. Когда implicit добежал до 3 секунд, explicit выдохся, implicit добежал ещё одну секунду и тоже закончился. Всего мы подождали 4 секунды
3. Implicit = 3000
Explicit = 4000
Это самый опасный вариант, тут лежит собака. Таймеры так же стартанули одновременно, через 3 секунды implicit говорит, что не нашёл элемента. В этот момент у explicit есть ещё время, implicit это видит и говорит: «ну тогда я на второй круг пойду». И в итоге мы ждём 2 раза по implicit итого 6 секунд вместо 4-ёх. Если бы explicit был 7, то ждали бы мы 9.

Что же с этим всем делать:
• (плохо) Делать большой implicit и ставить его в 0 тогда, когда мы ждём, что элемента не будет. Элементы пропадают в том числе когда мы этого не ждём. Т.е. implicitWait всегда должен быть маленьким.
• (лучше) Можно забить на особенности взаимодействия этих вейтеров сделать implicit маленьким и использовать explicit, зная, что он может ждать немногим больше, чем мы этого хотим.
• (хорошо) Лучше всего написать обёртку для explicit, которая будет сетить impliсit в ноль, ждать explicitly и сетить implicit обратно в дефолтное значение. Мой пример для протрактора: github.com/...​nnadiii/explicitWaiter.js
• (важно) И самое главное — никогда и ни под каким предлогом не использовать слипы (кроме маленьких слипов в кастомных поллингах с целью не зафлудить сервер).

Ждите правильно и стабильных всем тестов!

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Как то написано слишком категорично. Может если создатели вебдрайвера добавили sleep то они что-то знали? Неправильно конечно использовать его всегда и везде, но есть много сценариев когда sleep выручает если его использовать грамотно. Например пока в базе обновляются индексы или приложение имеет несколько баз данных и нужно подождать пока они синхронизируются (или любой другой backend processing который на UI вообще не виден). Можно конечно написать свой велосипед, пытаться обьяснять людям что так лучше, супортить его (а как мы знаем время = $), когда можно было обойтись простым browser.sleep(500). Что ваш заказчик скажет если узнает что вы потратили 2 дня на то что можно было сделать за минуту, что бы возможно(!) уменьшить время выполнения найтли рана на 500мс?
Или если фикс нужен уже сейчас, а времени на это в данный момент нет? Что по вашему лучше, скипнуть всю спеку и ждать пока появится время на нормальный фикс или пускай выполняется и делает свою работу, пусть даже с небольшим увеличением по времени?
Хотя за статью спасибо, неплохой ликбез для тех кто об этом раньше не слышал.

Ключевое:

если его использовать грамотно
По моему опыту не хватает «грамотно». Всегда есть сущьность, к которой можно привязаться для поллинга. Слип быстрее, но, если завтра индексация займёт 550мс — билд упадёт. Это ключевой момент. Даже когда со слипом быстрее и слип небольшой — я не знаю сколько времени это займёт завтра. Если есть готовые вейтеры, то исользовать их легко и это не занимает много времени. У нас бекенд тоже на протракторе (не спрашиваейте почему) и я использую слипы только для рестовых вейтеров в интервале полинга дабы не спамить сервер множеством запросов.
PS я видел слипы по пол часа... такой слип стоял на деплое чего-то (не помню чего) и такой большой он был, потому что это что-то локально поднималось дольше, чем на сервере ввиду мощьности локальной машины по сравнению с сервером.
Всегда есть сущьность, к которой можно привязаться для поллинга

но не всегда игра стоит свеч

Зависит от подхода. Если задаться целью сделать хорошо, то у меня ещё не было случаев, когда я позволил бы себе оставить слип в коде. Опять таки никто не гарантирует, что этого времени хватит завтра. Ну и теорию разбитых окон никто не отменял.
Если задача — сделать как можно быстрее, но, чтоб хоть как-то работало, то да — вооружился слипами и вперёд.

Неистово плюсую.
ExpectedConditions рулят

Я один для вейтов использую expectedConditions ?
Ну там browser.wait (protractor.expectedConditions.УСЛОВИЕ, timeout, ’шеф, всё пропало’).then (()=>{
Действо ();
});
И условий там полно и elementPresent и ElementToBeClickable и ElementComtainsText и elementDisplayed и всё это можно делать с .not

Сей топик про сами вейтеры, а не про условия (expectedConditions). Что использовать в вейтерах — дело случая и expectedConditions — вполне валидный и хороший вариант.

Просто не нужно писать тесты на JS

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

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

Если освоить камасутру, секс будет в удовольствие ;)

Слабый аргумент

2 часа, 7 минут. Буду ну вот очень благодарен за краткое содержание по сути.

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

...даже вот сразу и не знаю, чем заменил бы ) Но замечание принято.

чейнить, сетить
Всё там понятно.
Ещё важно, стараясь соблюсти чистоту мовы/языка, не начать придумывать новые слова.
Мне вот вчера пришлось отлаживать в FF. Интерфейс там был на украинском языке. Интерфейс дев тулов в том числе. Так вот debugger табу они перевели как Зневаджувач.
Только вчера узнал о существовании такого слова... Зато не заимствовали :)

Мы когда-то всей командой думали, что такое в виндофоне реп’яшки. Спойлер: это куки )

Пока что за чейнить лучшая мысля — зацепочивать )

Может всё-таки вооружитесь Бритвой Оккама? :)

Генадий привет!

Пацанский подгон сахара в твой код. Раз уж ты не юзаешь ExpectedConditions:

browser.wait(() => field.isPresent(), 5000, ‘Field not found’);
Можно поменять на
browser.wait(field.isPresent, 5000, 'Field not found')

Только учти что например с isDisplayed() так не прокатит — isDisplayed может бросить исключение если элемента нет, и твой код упадет, ExpectedCondition.visibilityOf ловит такие исключения, и возвращает false.

А можно вообще любое взаимодейтствие с элементами оборачивать в try{}catch{}(если что это про джаву) и самому обратабывтаь выдаюащие исключения)

Но зачем? Исключения нужны и ловить все без разбора плохо, особенно в тестах

А я где то сказал, что они не нужны?

Привет! Спасибо за сахарок, я писал уже об этом, а тут сам завтыкал ) Только ошибка получается: Failed: Cannot read property ’parentElementArrayFinder’ of undefined

тогда мой хак не сработал )
Это значит что референс на field потерялся

Я хз зачем использовать этого монстра. Тем же Imacros-ом можно сделать все в десятки раз быстрей и проще. Смотрел на видео как чел писал двух часов! заполнения трех несчастных полей и отправки формы. На имакросе хватит и 15 мин чтоб справится с этой задачей.

Не слышал про Imacros, но википедия говорит, что это record&playback, правильно?

а не в том числе? record&playback может подойти тлько для очень маленького проекта. Очень маленкого

а не в том числе все возможности силениума как минимум) и все нужные штуки там с файла считать обычно из коробки) статистику вывести. Код пишеться на связке basic подобного и js. Вообщем пока я смотрел как програмер писал 2 часа простой тест маленькой формы на силениуме. Я понял что напишу подобное за 10 мин. При этом оно будет еще перебирать результаты с файла.

Давай так, если вебдрайвер — это библиотека-драйвер к браузеру, есть протрактор — либа, которая дополняет функционал вебдрайвера и есть Jasmine — тест фреймворк с матчерами, репортерами и всем таким. Всё это счастье под JS. Что такое конкретно имакрос и под какой он язык?

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

а так если подробно интересно глянь ютуб туториалы по имакросу) та де пишут код) а не прост запись/воспроизведения.

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

0) Плагины для браузера не могут симулировать нативные браузерные взаимодействия. Клики в этих плагинах — это не клики мышкой, а javascript код который эмулирует клик мышкой — со всеми вытекающими (возможно именно для Imacros это не так, поскольку за 6 лет автоматизации первый раз слышу о его применении для автотестов)

1) Инструменты такого плана плохо расширяются и масштабируются — например когда стоит вопрос запускать в паралели на куче браузеров на регулярной основе на дженкинсе да с in-memory базой данных которую нужно наполнить данными перед тестами — боюсь без серьезного языка программирования вам не обойтись

2) Код писать сложней, и как следствие тесты поддерживать сложней — язык не широко распространен, специалистов которые будут готовы работать с этим инструментов очень мало, вспомогательных библиотек очень мало, комьюнити небольшое.

Я описал то с чем столкнулся на практике. Некого не пытаюсь переубедить. По крайней мере попробовать/посмотреть может пригодится для некоторых задач в тестировании. Сам инструмент простой и для вката и по скорости написание простого теста(20 полей, парочку чекбоксом, в парочку кнопок ввод данных с файла, выгрузка пару файлов) по другим параметром он скорей всего будет проиграть по сравнению с Силениумом(по этому и стандарт).

Вы сказали

Я хз зачем использовать этого монстра
Который по сути является улучшенными тормозными колодками для мота и предложили вместо этого кататься на коньках, при чём не спросили по какой поверхности то ездить надо будет. У нас 15 джоб, сотни файлов, тысячи строк кода на JS, питоне и баше. Есть тесты, которые вообще браузер не используют, нам коньки не подходят. Я понимаю, что
Некого не пытаюсь переубедить. По крайней мере попробовать/посмотреть может пригодится для некоторых задач в тестировании.
но не спешите критиковать и давать советы не узнав проблемы. Каждое решение должно решать какую-то определённую проблему.

Генадий, ты что то накрутил:)

Во первых «чем проще тем лучше» — если это конечно не приводит к сильно большим жертвам. Там больше таймаут там меньше.... Там это ок, там могут быть проблемы. Зачем так сложно?

В данном случае — использовать и неявные ожидания и явные — это перебор. Зачем? Да еще и в протракторе о_О? В котором вся динамика ожидается и так неявно встроенным waitForAngular во всех действия!

И того, во-первых — протрактор — это инструмент для ангуляр приложений — а там в принципе вейты не нужны, никакие :)

Конечно можно конфигурировать таймаут для waitForAngular, но это уже другая тема.

Во-вторых — неявные ожидания — ждут до появления в доме а не до видимости — что лишено любого смысла в реальных тестах. Ведь пользователю что-бы работать с элементом — важно его видеть!

Что сразу отметает за ненужностью.

Там где не ангуляр. Там — эксписит вейты — решают, да. Без них никак. Таков уж наш мир динамических веб приложений.

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

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

Но. Манкипатчинг — не лучшее для этого решение. Тут уже нужно подходить с умом. Создавать свою альтернативу лейзи ЕлементФайндера — как в протракторе. И снова — не нужно мешать козу с яйцом. Протрактор — не для обычных приложений. Потому что для них он — оверхед, ничего не дающий. Протрактор — заточен именно под ангуляр приложения.

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

Хех ) Поехали...

использовать и неявные ожидания и явные — это перебор
я же не использую их вместе. Когда работает один — другой отдыхает.
протрактор — это инструмент для ангуляр приложений — а там в принципе вейты не нужны, никакие
вот это самое большое заблуждение. Зависит от приложения. У нас протрактор хендлит много, но не всё. Бывают случаи, когда ангуляр сказал, что справился и element not found exception
неявные ожидания — ждут до появления в доме а не до видимости
Этого хватает в большинстве случаев. А где не хватает — waitReady
Там где не ангуляр. Там — эксписит вейты — решают, да
Имплисит вы хотели сказать? Там нужно ждать каждый элемент и зачем же мне каждый ждать явно?
Но твоя реализация — это банальный манки патчинг на основе селениумских родных эксплисит вейтов
в чём банальность? Просто эксплисит вейт никак не рабоатет с имплиситом и его нельзя чейнить. И зачем мне везде писать одинаковый вейтер, когда можно вынести его в метод? Чем проще — тем лучше, сами говорили.
Ты бы лучше реализовал свои неявные ожидания которые умеют ждать до видимости
пока не вижу в этом необходимости для моего проекта. Надо будет — сделаем, не проблема.
Манкипатчинг — не лучшее для этого решение.
Моё решение заменило вот это: gist.github.com/...galu/2939aad2b2e31418c1bb и прекрасно решает наши проблемы.
Создавать свою альтернативу лейзи ЕлементФайндера — как в протракторе.
Я ж и так в протракторе ) А своя альтернатива для не ангуляр сайтов — это имплисит вейт. Протрактор ждёт, пока отработает ангуляр, который «говорит, что готов» когда страничкой уже можно пользоваться. Не ангуляр ничег оне говорит и каждый элемент нужно ждать. Обычно страницы грузятся быстро, так что имплисит вейт 2 2 секунды (в зависимости от приложения) решает.
Протрактор — не для обычных приложений.
У нас ангуляр, всё нормально, не переживайте )
В селениуме фишка явных ожиданий особенно в том — что ними можно ждать чего угодно. Текста у элемента, значения какого то атрибута. И так далее.
пока что не вижу применения для нашего приложения. Но, опять таки, надо будет — сделаем, не проблема.

*что имплисит вейт 2 секунды

нет я имел в виду эксплисит... ладно... ты как то сильно отфильтровал мой посыл...

думаю я напишу большой пост прям тут где раскажу кратко о том «как оно на самом деле должно все работать» и намного намного проще чем твоя математика с явными и неявными селениумскими ожиданиями:-)

Круто, ждёмс. А то как-то пока не сильно понятно для неагуляров не использовать имплиситы, а каждый элемент с эксплиситом использовать... Если, конечно, не свой велосипед, который ждёт эксплиситли под капотом самостоятельно.

твоя математика с явными и неявными селениумскими ожиданиями
Эт не моя математика, это так хорошие люди сделали. Да и не сложная та математика, если присмотреться.
В данном случае — использовать и неявные ожидания и явные — это перебор. Зачем? Да еще и в протракторе о_О? В котором вся динамика ожидается и так неявно встроенным waitForAngular во всех действия!
И того, во-первых — протрактор — это инструмент для ангуляр приложений — а там в принципе вейты не нужны, никакие :)
Конечно можно конфигурировать таймаут для waitForAngular, но это уже другая тема.

Ничего ничего, жизнь еще покажет тебе кривой код где waitForAngular тебе будет недостаточно )

Я скажу что нужен и waitForAngular и ImplicitWait и ExplicitWait и в ангуляр и в неангуляр приложениях. Просто у тебя в неангуляр будешь ждать что ajax запросы прошли и другие фоновые штуки, а в ангуляре можно ждать побольше всякого барахла.

Идея с implicitWait который будет ждать isDisplayed() а не isPresent() хороша, но тут много подводных камней я сразу сходу вижу. Но мысль здравая! Я бы поработал в этом направлении!

жизнь уже показывала что те случаи на которые ты намекаешь — случаи кривых ангуляр приложений:-) где протрактор сам по себе не сильно хороший выбор;-)

о подводных камнях делись:-) А то мы тут уже года 4 селениде используем с неявными ожиданиями до видимости и ни на один не натолкнулись:-)

А какой же выбор нужно делать? И такой ещё вопрос. Предположим, что есть магическая туловина, которая лучше протрактора работает с кривым ангуляром. Назовём её суперТул. И вот мы собрались пилить новый продукт и решили, что юай будет ангуляровкий. Тогда нужно выбрать, чем же мы будем тестировать. Главный автоматизатор говорит, что, мол, если ангуляр, то, стало быть, протрактор. А главный фронт-ендщик отвечает, что юай то он хреновенький собирается запилить, то протрактор не подойдёт. Надо сразу под галимый юай суперТул покупать. И менеджмент сразу соглашается на суперТул, ведь юайщики то молодцы, предупредили, что хреновый юай нам сделают. Они то знают...

нужно взять и написать в кои то веки что то адекватное оупенсорсное за которое не нужно будет платить:-) типа селениде/селена) с имплиси т вейтами до визибилити) с ожидающими по кондишенам асертами. и с возможностью конфигурировать неявные хуки перед действиями на основе которых включать не явный вейтФорАнгуляр тогда когда без него никак.

я вот начал потихоньку:-) github.com/automician/selenidejs

надеюсь летом найду время закончить кор...

Ну что ж, если это будет реально лучше и удобней, чем протрактор, то будет здорово. Желаю удачи! (без сарказма)

Добрый день. А зачем вся эта статья, если
www.seleniumhq.org/...plicit-and-implicit-waits

WARNING: Do not mix implicit and explicit waits. Doing so can cause unpredictable wait times. For example setting an implicit wait of 10 seconds and an explicit wait of 15 seconds, could cause a timeout to occur after 20 seconds.

День добрый. Я видел эту статью.
Во-первых, там не написано почему так происходит
во-вторых, это ни разу не «unpredictable», там нет Math.random в механизме вейтеров и вполне можно всё предсказывать, если почитать чего выше написано
в-третьих, не все, может, видели ту статью
в-четвёртых, вам как-то помешало бы жить, если б было просто написано тоже самое, но на этом ресурсе и на русском? Я, например, когда что-то ищу бывает ищу в первую очередь именно по хабру или доу.

Статья, это то что вы написали выше, а я вам дал ссылку на официальную документацию Selenium. Почему вы считаете что вы лучше знаете механизмы работы селениума лучше его разработчиков?

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

А вы вообще читали, пробовали? Что именно разгребать, ткните носом, что не так. Или просто так решили отписаться, что всё г*но?

И вы написали не тоже самое, что я процитировал :)

Ну так там же английским по серому написано

unpredictable
а я говорю — покажите код и я скажу сколько он будет ждать. И написал выше почему так происходит. Или вы думаете, что у нас 15 джоб тупо угадывают постоянно?
Поведение стабильно, а не unpredictable

Генадий, это не нам нужно показывать а тебе. Ты же статью пишеш заявляющую то что противоречит официальной документации. Это тебе нужно свою «еретическую» точку зрения зачищать ;)

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

Там же полинг должен судя по всему быть как у неявных ожиданий так и у явных. И именно засчет двойного полинга — могут быть дополнительный задержки. А это еще и джаваскрипт который асинхронный — и там все еще более «анпредиктебл» ;)

В документации сказано варнинг, так не делайте. И я говорю — так не делайте. Единственное, с чем я там не согласен — это слово unpredictable. Imlicit=10, explicit=15 итого 20 так вот, если имплисит будет 21, то ждать мы будем 30 и ничего анпредиктабильного нет. Не верите — протрактор нам судья.

Ты вот например приводишь свои расчеты только по целому таймауту. А что же ты полинг не учитываешь?
не понял сути вопроса.
А это еще и джаваскрипт который асинхронный — и там все еще более «анпредиктебл» ;)
До сих пор в JS я не видел ничего непредсказуемого. Это однопоточный! язык. Он для меня был непредсказуемым, пока я не понимал как он работает. Там тоже не рабоатет рандом — как вы напишете — так он и будет работать. Нет там «анпредиктебл»

Опечатка, продублирую правильно:
Imlicit=10, explicit=15 итого 20 так вот, если explicit будет 21, то ждать мы будем 30, Imlicit=20, explicit=15 итого 20

нет сейчас под рукой компа... что бы проверить и скинуть скриншота... поэтому могу ошибаться... но если мне не изменяет память то даже указывая таймаут точно в 4 секунды по факту оно будет ждать с дельтой и разбросом... это можно увидеть в сообщениях об ошибкё в случае если вейт не дождался...

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

там может быть ошибка в 100 мс... это может быть не существенно... а может и существенно... все зависит...

просто все оно не так просто на самом деле... и мне кажется, что если ты взялся писать статью которая рекомендует что то не совсем то что в документации то нужно быть более тщепетильным...

и не писать вдруг что — пускай они объясняют... это твоя ответственность что то объяснять если оно ново...

все как в защитах дипломов в универе...

нет сейчас под рукой компа...
та я особо не спешу. Take your time
но если мне не изменяет память то даже указывая таймаут точно в 4 секунды по факту оно будет ждать с дельтой и разбросом...
время выполнения скрипта в вейты не плюсуем. Можем даже сыграть в рулетку. Вы мне говорите сеты для вейтов, а я скажу сколько будем ждать + время выполнения скрипта.
о поллинге — речь о том, что у не явных ожиданий свой поллинг а у явных свой...
полинг полингом, а таймаут таймаутом (но я проверю, хотя разницу в доли проценат не считаю существенной).
там может быть ошибка в 100 мс...
если она и есть, то её легко спутать с временем выполнения скрипта. Речь же о конкретных примерах 15 и 10 итог 20, но по факту он 21,3, например. Это ж ещё от браузера и интернета зависит.
и мне кажется, что если ты взялся писать статью которая рекомендует что то не совсем то что в документации
Я тоже не рекомендую пользоваться ими одновременно, как и в доке. Я тут просто нострадамусом решил заделаться для всех, кто unpredictable
и не писать вдруг что — пускай они объясняют...
А кто чего объяснил? Я пока не вижу, что я мог бы поменять или убрать. Тут только Саша Хотемский и сахарку предложил (только не совсем подошло) и даже подкомититься в гитхаб хотел с хорошей мыслью. А так увижу — скажу большое спасибо и сделаю.
все как в защитах дипломов в универе...
Там я жульничал, тут всё по-честному )

Мы вот с вами больше всех вместе взятых тут воды вылили. Я, вот, почему-то верю, что именно с вами может получиться хороший конструктив, только вам компа не хватает.

во-вторых, это ни разу не «unpredictable»
может, специально нагоняют драматизма, чтоб новички пугались и не миксовали всем во вред?

Вполне вероятно, я тоже об этом думал. Типа прийдёт время, человек задумается и разберётся. Если все вокруг не будут кричать — не трогай, оно же анпредиктабл.

в protractor есть „свой explicit wait” — Expected Conditions. его и рекомендуют использовать.
www.protractortest.org/...tractorExpectedConditions

Я, если честно, не особо юзаю ЕС, но на сколько я понимаю, это не вейтер, а ожидаемое состояние, которое передаётся в вейтер. browser.wait принимает колбек и время
browser.wait(() => field.isPresent(), 5000);
вместо колбека, в котром я делаю isPresent, можно было бы вызвать функцию ЕС.visibilityOf(field), которая по идее, должна вернуть функцию, тем самым передав колбек в вейтер. ЕС ж не ждёт под капотом...?
Пример с ссылки:
var EC = protractor.ExpectedConditions;
// Waits for the element with id ’abc’ to be visible on the dom.
browser.wait(EC.visibilityOf($(’#abc’)), 5000);

Ну у тебя и заявление, как для автора статьи — «я не особо юзаю», «насколько я понимаю» :)
Как можно людям обьяснять что такое эксплисит вейты, никак не упомянуть о кондишенах в статье, и потом такое в комментариях писать:)

Ты не обижайся:) Я не по злому... По доброму :)

Кондишены — это очень полезная штука (если речь не о ангуляр приложениях — где они действительно не нужны по сути...). Ведь з задержкой не только элемент может появится на странице, а и текст может у него изменится с задержкой. И как ты тогда такой текст будешь проверять?

Я не писал про EC в статье ни слова именно потому, что их не юзаю и нет необходимости. Что вы передадите а вейтер, ЕС или любой другой колбек, который вернёт булиан — нет разницы никакой.

если речь не о ангуляр приложениях — где они действительно не нужны по сути...
у нас ангуляр
Давайте мы в нашем споре сделаем паузу, я признаюсь вот лично вам, по-честному, что я то в основном пишу бек-енд тесты и в юай часть залез только потому, что увидел, что мы юзаем что-то неправильно,
а вы по-честному откроете ваш любимый редактор кода, поиграетесь, помиксуете вейтеры и покажете мне пруф, что вот мол смотри: один и тот же код запустил несколько раз и он вот ждал совсем по-разному и вообще unpredictable. И мы тогда продолжим разговор, а то некоструктивно получается...
Я не по злому... По доброму :)

Ну это не только у протрактора, ExpectedConditions есть помоему во всех языковых биндингах для селенума.

А идея «Ожидаемых Состояний» очень простая — а давайте заготовим набор predicate, для типичных состояний наших элементов на странице, и их будет легко использовать в комбинации с .wait()

В той же java-selenium — кондишинов уже понаписывали огромную гору, тысячи их :)

Неистово плюсую.
ExpectedConditions рулят

Підписатись на коментарі