AB
но может быть неудобно для JS, да
Size: a a a
2019 November 12
AP
основанный на исключениях? это типично для Java (и его аналогов)
основанный на том что проверка на присутствие одна ( неявная ), а проверка на отсутствие совершенно другая ( ошибка на поиске )
Ri
Думал делать условия в тех тестах где будет меняться логика, но если версий больше 2х уже малочитабельным становиться сам тест. Есть идея вынести все тестовые данные в отдельные файлы и в них следить за переменной окружения и подсовывать данные согласно ей.
AB
кстати, я правильно понимаю, что "оригинальный" селенид, на Java, не делает перепоиск для списков?
AP
вместо чего то аля element.should(be.absent), element.should(be.present)
BO
ИМХО это хреновый апи если один и тот же роут хендлит 2 типа запросов
обычный json-rpc. ничего криминального
AP
выходит что для проверки что элемент улетел в жадном его либо надо искать ( что не совсем интуитивно как по мне ), либо если он был найдет ранее и лежит в переменной то...кликнуть? вызвать любую функцию и ожидать стейл?
AB
выходит что для проверки что элемент улетел в жадном его либо надо искать ( что не совсем интуитивно как по мне ), либо если он был найдет ранее и лежит в переменной то...кликнуть? вызвать любую функцию и ожидать стейл?
да, вызвать любую функцию и ловить исключение
AB
можно, конечно, добавить специальную фунцию-пустышку ровно для этой проверки
AB
то есть добавить в API метод вроде element.isStale()
VG
>Только вот зачем изобретать велосипеды снова и снова - если можно это решить один раз на уровне самого инструмента
вроде уже выше писали что всем нужно по разному. в каждом случае удобен тот или иной подход. почему в инструмент нужно тащить тот подход, который нужен тебе?
вроде уже выше писали что всем нужно по разному. в каждом случае удобен тот или иной подход. почему в инструмент нужно тащить тот подход, который нужен тебе?
всем нужно по-разному - да. Я хочу чтобы в инструменте было консистентное поведение
Почему я могу определить
Почему я могу определить
const a = $(‘.missing’)где-угодно в коде, а
const b = $(‘.missing’).$(‘.sublement’)уже нельзя…
BO
всем нужно по-разному - да. Я хочу чтобы в инструменте было консистентное поведение
Почему я могу определить
Почему я могу определить
const a = $(‘.missing’)где-угодно в коде, а
const b = $(‘.missing’).$(‘.sublement’)уже нельзя…
справедливо
VG
короче надо наверное тикет перефразировать - а то выходит что я топлю в нем за конкретную реализацию, а не пытаюсь обяснить проблему
AP
короче надо наверное тикет перефразировать - а то выходит что я топлю в нем за конкретную реализацию, а не пытаюсь обяснить проблему
ты лучше все кейсы перечисли сразу, чтоб наверняка
VG
сейчас допишу в комент
AP
element.element
element.all
all.element
all.all (?)
element.all
all.element
all.all (?)
AP
последний наверно надо исключить потому что там как минимум 2 варианта поведения
VG
all.element
all.all (?)
это сейчас не работает и не будет (да и смысла нет)
all.all (?)
это сейчас не работает и не будет (да и смысла нет)
VG
или ты имеешь в виду all.map(e => e.all) ?
AP
как нет?
all.elementAt(5)
----
all.mapToInnter(...)
all.allInEach(...)
all.elementAt(5)
----
all.mapToInnter(...)
all.allInEach(...)