cm
там можно задать сколько ждать до появления
Size: a a a
2020 October 07
ДЛ
там можно задать сколько ждать до появления
ладно, спасибо за попытку помочь ❤️
BO
@boris_osipov ```
Actual value: visible:true``` этот кусок при падении заново проверяет видим ли элемент? А не берет его значение видимости с $("dfsdfsdf").should(visible)?
da
OS
Всем привет, подскажите пожалуйста, почему кликает не туда?
OS
is not clickable at point (122, 394) selenide
OS
через developer tool находит только один XPath, больше такого нет //button[@id='okBtn' and contains(text(), 'Да')]
AS
пришлось добавить специальную команду, которая логи удаляет. но лучше бы они не писались вообще :)
Не понял. А разве у вас билд не начинается с команды "gradle clean" или "mvn clean"?
AB
нет, не начинается
AS
Так надо добавить. И всё сразу вылечится.
AB
нет, не хочу такое лечение
AS
Почему?
Без этого по-любому будет задница. Уберём логи - проект быстро забьётся чем-то ещё.
Без этого по-любому будет задница. Уберём логи - проект быстро забьётся чем-то ещё.
AB
до сих пор не забивался
AB
сборщик прекрасно отслеживает зависимости и пересобирает ровно то, что нужно. какой смысл каждый раз чистить?
OS
через developer tool находит только один XPath, больше такого нет //button[@id='okBtn' and contains(text(), 'Да')]
При этом элемент уже появился и не дожидаясь действия click() - переходит к другому элементу
AS
Обычно так и делают: инкрементальную компиляцию используют локально, а на дженкинсе билдят с нуля. Чтобы исключить влияние предыдущих сборок.
AB
не уверен про "обычно". можно опрос устроить :)
AB
что ещё за влияние предыдущих сборок? если оно у вас есть — его надо устранить, а не чистить каждый раз
AS
Если это проект автоматизации тестирования, то там компиляция как раз очень маленькая часть, а основное время занимает прогон тестов.
AB
тесты не в отдельном проекте, они встроены в большую сборку продукта. поэтому каждый раз чистить — не вариант, даже не уговаривайте
AB
проще добавить отдельную команду, которая удаляет ненужные логи