Size: a a a

2019 November 12

AB

Alexei Barantsev in JS for testing
но может быть неудобно для JS, да
источник

AP

Alexander Popov in JS for testing
Alexei Barantsev
основанный на исключениях? это типично для Java (и его аналогов)
основанный на том что проверка на присутствие одна ( неявная ), а проверка на отсутствие совершенно другая ( ошибка на поиске )
источник

Ri

Rustam is not a function in JS for testing
Думал делать условия в тех тестах где будет меняться логика, но если версий больше 2х уже малочитабельным становиться сам тест. Есть идея вынести все тестовые данные в отдельные файлы и в них следить за переменной окружения и подсовывать данные согласно ей.
источник

AB

Alexei Barantsev in JS for testing
кстати, я правильно понимаю, что "оригинальный" селенид, на Java, не делает перепоиск для списков?
источник

AP

Alexander Popov in JS for testing
вместо чего то аля element.should(be.absent), element.should(be.present)
источник

BO

Boris Osipov in JS for testing
Oleksandr Khotemskyi
ИМХО это хреновый апи если один и тот же роут хендлит 2 типа запросов
обычный json-rpc. ничего криминального
источник

AP

Alexander Popov in JS for testing
выходит что для проверки что элемент улетел в жадном его либо надо искать ( что не совсем интуитивно как по мне ), либо если он был найдет ранее и лежит в переменной то...кликнуть? вызвать любую функцию и ожидать стейл?
источник

AB

Alexei Barantsev in JS for testing
Alexander Popov
выходит что для проверки что элемент улетел в жадном его либо надо искать ( что не совсем интуитивно как по мне ), либо если он был найдет ранее и лежит в переменной то...кликнуть? вызвать любую функцию и ожидать стейл?
да, вызвать любую функцию и ловить исключение
источник

AB

Alexei Barantsev in JS for testing
можно, конечно, добавить специальную фунцию-пустышку ровно для этой проверки
источник

AB

Alexei Barantsev in JS for testing
то есть добавить в API метод вроде element.isStale()
источник

VG

Vitalii Grygoruk in JS for testing
Boris Osipov
>Только вот зачем изобретать велосипеды снова и снова - если можно это решить один раз на уровне самого инструмента
вроде уже выше писали что всем нужно по разному. в каждом случае удобен тот или иной подход. почему в инструмент нужно тащить тот подход, который нужен тебе?
всем нужно по-разному - да. Я хочу чтобы в инструменте было консистентное поведение

Почему я могу определить
const a = $(‘.missing’)
где-угодно в коде, а
const b = $(‘.missing’).$(‘.sublement’)
уже нельзя…
источник

BO

Boris Osipov in JS for testing
Vitalii Grygoruk
всем нужно по-разному - да. Я хочу чтобы в инструменте было консистентное поведение

Почему я могу определить
const a = $(‘.missing’)
где-угодно в коде, а
const b = $(‘.missing’).$(‘.sublement’)
уже нельзя…
справедливо
источник

VG

Vitalii Grygoruk in JS for testing
короче надо наверное тикет перефразировать - а то выходит что я топлю в нем за конкретную реализацию, а не пытаюсь обяснить проблему
источник

AP

Alexander Popov in JS for testing
Vitalii Grygoruk
короче надо наверное тикет перефразировать - а то выходит что я топлю в нем за конкретную реализацию, а не пытаюсь обяснить проблему
ты лучше все кейсы перечисли сразу, чтоб наверняка
источник

VG

Vitalii Grygoruk in JS for testing
сейчас допишу в комент
источник

AP

Alexander Popov in JS for testing
element.element
element.all
all.element
all.all (?)
источник

AP

Alexander Popov in JS for testing
последний наверно надо исключить потому что там как минимум 2 варианта поведения
источник

VG

Vitalii Grygoruk in JS for testing
all.element
all.all (?)
это сейчас не работает и не будет (да и смысла нет)
источник

VG

Vitalii Grygoruk in JS for testing
или ты имеешь в виду all.map(e => e.all) ?
источник

AP

Alexander Popov in JS for testing
как нет?

all.elementAt(5)
----
all.mapToInnter(...)
all.allInEach(...)
источник