B
можно ждать не только displayed или presence, можно ждать и нужных css стилей, и позиции элемента, и размера элемента, и что угодно...
Можно и анимацию принудительно отключить, если он на css завязан
Size: a a a
2020 January 11
OK
Можно и анимацию принудительно отключить, если он на css завязан
да, это тоже хороший вариант
A
С таким еще не сталкивался. Буду копать, спасибо
M
Artur
объясните кто-то, почему у всех такое отношение к thread.sleep'у?
Ты блочишь поток в слип
M
Это bad practise
EB
Это bad practise
О, а где можно почитать про “bad practise” и слип в треде побольше? Ну или вашими словами передайте
B
Ты блочишь поток в слип
Какой там поток блочится?
M
О, а где можно почитать про “bad practise” и слип в треде побольше? Ну или вашими словами передайте
AK
Artur
вот об этом речь:
public void waiter(){
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
public void waiter(){
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
Эм... на сайте в любом случае есть какой-то признак, который позволяет вам, как пользователю, определить, что сайт загружен, так? Если это так, то вам просто нужно найти этот элемент в DOM и понять, что с ним происходит до, во время и после загрузки сайта. И отслеживать это изменение в самом тесте.
AK
Artur
Всем привет.
Практикуется ли такое в вашей стези, чтобы Thread.sleep запихнуть в отдельный метод, что бы не засорять код трай-кетчами?
Wait'ом у меня не получается сделать то, что мне нужно, ибо элемент, который он ищет и "ждет", пока он станет кликабельным, появляется сразу с загрузкой страницы и это никоим образом не заставляет его сделать задержку. А она нужна, чтобы страница секунд 3 пришла в себя и далее я с ней делаю манипуляции.
Практикуется ли такое в вашей стези, чтобы Thread.sleep запихнуть в отдельный метод, что бы не засорять код трай-кетчами?
Wait'ом у меня не получается сделать то, что мне нужно, ибо элемент, который он ищет и "ждет", пока он станет кликабельным, появляется сразу с загрузкой страницы и это никоим образом не заставляет его сделать задержку. А она нужна, чтобы страница секунд 3 пришла в себя и далее я с ней делаю манипуляции.
Кмк, вы ждете не тот элемент) Т.е. у вас два разных события:
* страница загружена, т.к. элемент Х - видимый/кликабельный/ИмеетКакоетоСвойство.
* нужно кликнуть на какой-то элемент У, когда он станет кликабельным.
И второе событие происходит раньше первого.
* страница загружена, т.к. элемент Х - видимый/кликабельный/ИмеетКакоетоСвойство.
* нужно кликнуть на какой-то элемент У, когда он станет кликабельным.
И второе событие происходит раньше первого.
BO
Therefore, I find it fine to use Thread.sleep here. As you said, spawning a separate thread when you are going to block the current thread anyways seems to complicate things without merit.
EB
it's frequently used in an ill attempt to fix a race condition, used where notification based synchronization is a much better choice
По мне это не bad practice, а bad misuse
По мне это не bad practice, а bad misuse
EB
Метод не виноват, что его используют идиоты. Он был придуман для сотен других полезных ситуаций
B
Вы только там прочитали, что это бэд практис?
AZ
This method is handy when you want to introduce a short pause into your thread execution. For example, imagine you have to update 100 000 rows in a database, but in order to lower the impact on the database you are required to introduce breaks of, say 2 seconds, between your update queries
M
Вы только там прочитали, что это бэд практис?
Нет, когда начинаешь работать с потоками, сталкиваешься с этим
B
Но тут речь об UI. Там нет таких проблем
AZ
https://automationintesting.com/selenium/java/lessons/waits.html
Тут тоже, насколько я понял, советуют быть осторожнее со thread.sleep и рекомендуют wait.until
Тут тоже, насколько я понял, советуют быть осторожнее со thread.sleep и рекомендуют wait.until
AZ
Не знаю правда, насколько можно тем или иным ресурсам доверять.