O
LockSupport.parkNanos() не кидает чекед эксепшенов
Size: a a a
2020 January 11
O
Но может не сработать
B
Слипы как временное решение — это ок. Другое дело, что чаще всего там, где я их видел все решается ожиданиями. Но иной раз если послушать людей, то все носятся с ними, как дурак со ступой, абсолютно игнорируя другие места для улучшения производительности пайплайна.
Оцените сколько тратят время тесты на ожидание, характер запуска тестов, сколько их нужно успевать запускать на полную / частичную регрессию как в реальной жизни это мешает разработке с вашим размером команды и доступности ресурсов. А ещё некоторые ожидания бывает дороже починить чем время время разработчика автотестов. Единственное что однозначно должно присутствовать в строке с ожиданием — это объяснение причины так делать. Ответишь — и ты на полпути к лучшему решению.
Оцените сколько тратят время тесты на ожидание, характер запуска тестов, сколько их нужно успевать запускать на полную / частичную регрессию как в реальной жизни это мешает разработке с вашим размером команды и доступности ресурсов. А ещё некоторые ожидания бывает дороже починить чем время время разработчика автотестов. Единственное что однозначно должно присутствовать в строке с ожиданием — это объяснение причины так делать. Ответишь — и ты на полпути к лучшему решению.
Так и было у меня. Было проще налепить слип на 300мс и забыть. И ... ничего не произошло.
O
У любого вейтера все равно слип внутри
EB
Да, просто он чаще всего экономит больше времени делая в цикле проверок чаще. Иногда чтобы не нагружать опрашиваемый ресурс дискретизация задержки не равномерная: например по экспоненте
AZ
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();
}
}
У меня в проекте сплошь и рядом похожие ситуации. Только я бэк тестирую. От слипов отказался. Долблю циклом while пока не получу нужный ответ от системы или не отвалюсь по тайм-ауту. Ответ то может раньше придти. Смысл ждать лишнее время?
Например, у меня есть требование, что ответ должен придти не позже, чем за 30 секунд, поэтому ставлю с запасом 31 секунду.
Если нефункциональных требований нет, стараюсь уточнить у аналитиков и разработчиков, сколько примерно в каждом конкретном бизнес-процессе ждать ответ (потому что есть сложные аналитические сервисы, которые статистику считают, а есть просто подтверждающие кодом ответа, что все ок) и уже из этого стараюсь исходить.
Например, у меня есть требование, что ответ должен придти не позже, чем за 30 секунд, поэтому ставлю с запасом 31 секунду.
Если нефункциональных требований нет, стараюсь уточнить у аналитиков и разработчиков, сколько примерно в каждом конкретном бизнес-процессе ждать ответ (потому что есть сложные аналитические сервисы, которые статистику считают, а есть просто подтверждающие кодом ответа, что все ок) и уже из этого стараюсь исходить.
B
Xpath уже не обсуждаем. )) Перешли на слипы
AZ
Хотя не знаю, может у вас на ui какая-то своя специфика?
OK
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();
}
}
так не лови и все, хай летит в рантайм
AZ
Но думаю, что все-таки нет) Логика, то, по идее,одна и та же.
AZ
В общем я делаю какой-то флаг, которым обозначаю, что нужный ожидаемый результат получен.
boolean allIsOk;
long expired = System.currentMillis() + количество миллисекунд
while (!allIsOk && System.currentMillis() < expired)
{
код для получения результата и проверки на соответствие ожидаемому.
Если соответствует, allIsOk помечаем как true и завершаем цикл
}
Также если шаг планируется запустить несколько раз (например, несколько платежек сделать и проверить, что они нормально сформировались, после цикла сбрасываем allIsOk на false)
boolean allIsOk;
long expired = System.currentMillis() + количество миллисекунд
while (!allIsOk && System.currentMillis() < expired)
{
код для получения результата и проверки на соответствие ожидаемому.
Если соответствует, allIsOk помечаем как true и завершаем цикл
}
Также если шаг планируется запустить несколько раз (например, несколько платежек сделать и проверить, что они нормально сформировались, после цикла сбрасываем allIsOk на false)
A
Есть на сайте джаваскриптовая(наверное) анимация, которая при нажатии выдвигается в центр страницы, занимает это секунду времени. При этом, xpath никак не меняется, чтобы отследить его и дождаться, когда он будет видимым.
Без слипа тесты проходят не все, с переменным успехом 15/20, если поставить слип, то всегда получается 20/20. Можно, конечно, поймать пулю в голову и начать подключать джаваскрипт скроллы, клики в пустоту, чтобы занять это время "тольколишьнеслипами". Но зачем?
Без слипа тесты проходят не все, с переменным успехом 15/20, если поставить слип, то всегда получается 20/20. Можно, конечно, поймать пулю в голову и начать подключать джаваскрипт скроллы, клики в пустоту, чтобы занять это время "тольколишьнеслипами". Но зачем?
AZ
Отмечу, что нефункциональные требования (а именно, производительность в разных видах) крайне важны, так как влияют на время прохождения тестов, а оно влияет на получение обратной связи командой через результаты, полученные из системы непрерывной интеграции.
Когда на проект пришел, там блин тоже слипы были понатыканы, и результаты этого были, мягко говоря, неутешительные, даже если все тесты проходили.
Когда на проект пришел, там блин тоже слипы были понатыканы, и результаты этого были, мягко говоря, неутешительные, даже если все тесты проходили.
OK
В общем я делаю какой-то флаг, которым обозначаю, что нужный ожидаемый результат получен.
boolean allIsOk;
long expired = System.currentMillis() + количество миллисекунд
while (!allIsOk && System.currentMillis() < expired)
{
код для получения результата и проверки на соответствие ожидаемому.
Если соответствует, allIsOk помечаем как true и завершаем цикл
}
Также если шаг планируется запустить несколько раз (например, несколько платежек сделать и проверить, что они нормально сформировались, после цикла сбрасываем allIsOk на false)
boolean allIsOk;
long expired = System.currentMillis() + количество миллисекунд
while (!allIsOk && System.currentMillis() < expired)
{
код для получения результата и проверки на соответствие ожидаемому.
Если соответствует, allIsOk помечаем как true и завершаем цикл
}
Также если шаг планируется запустить несколько раз (например, несколько платежек сделать и проверить, что они нормально сформировались, после цикла сбрасываем allIsOk на false)
поздравляю, вы переизобрели waitUntil
AZ
Artur
Есть на сайте джаваскриптовая(наверное) анимация, которая при нажатии выдвигается в центр страницы, занимает это секунду времени. При этом, xpath никак не меняется, чтобы отследить его и дождаться, когда он будет видимым.
Без слипа тесты проходят не все, с переменным успехом 15/20, если поставить слип, то всегда получается 20/20. Можно, конечно, поймать пулю в голову и начать подключать джаваскрипт скроллы, клики в пустоту, чтобы занять это время "тольколишьнеслипами". Но зачем?
Без слипа тесты проходят не все, с переменным успехом 15/20, если поставить слип, то всегда получается 20/20. Можно, конечно, поймать пулю в голову и начать подключать джаваскрипт скроллы, клики в пустоту, чтобы занять это время "тольколишьнеслипами". Но зачем?
Чтобы уменьшить время прохождения тестов, как говорилось выше. Может страница отлипнуть через 30 секунд, а может через 2. Получается, что тратим на прохождение лишние 28 секунд.
OK
Artur
Есть на сайте джаваскриптовая(наверное) анимация, которая при нажатии выдвигается в центр страницы, занимает это секунду времени. При этом, xpath никак не меняется, чтобы отследить его и дождаться, когда он будет видимым.
Без слипа тесты проходят не все, с переменным успехом 15/20, если поставить слип, то всегда получается 20/20. Можно, конечно, поймать пулю в голову и начать подключать джаваскрипт скроллы, клики в пустоту, чтобы занять это время "тольколишьнеслипами". Но зачем?
Без слипа тесты проходят не все, с переменным успехом 15/20, если поставить слип, то всегда получается 20/20. Можно, конечно, поймать пулю в голову и начать подключать джаваскрипт скроллы, клики в пустоту, чтобы занять это время "тольколишьнеслипами". Но зачем?
можно ждать не только displayed или presence, можно ждать и нужных css стилей, и позиции элемента, и размера элемента, и что угодно...
AZ
поздравляю, вы переизобрели waitUntil
Да я и не помнил, как это называется. Просто логику хотел пояснить)
AZ
Я вот заинтересовался, какие нюансы на ui у вас происходят. Да на ui все посложнее, конечно. Спасибо за пояснения)
AZ
В общем на ui, как уже вижу, сложнее задать ожидаемый результат.
AZ
Artur
Есть на сайте джаваскриптовая(наверное) анимация, которая при нажатии выдвигается в центр страницы, занимает это секунду времени. При этом, xpath никак не меняется, чтобы отследить его и дождаться, когда он будет видимым.
Без слипа тесты проходят не все, с переменным успехом 15/20, если поставить слип, то всегда получается 20/20. Можно, конечно, поймать пулю в голову и начать подключать джаваскрипт скроллы, клики в пустоту, чтобы занять это время "тольколишьнеслипами". Но зачем?
Без слипа тесты проходят не все, с переменным успехом 15/20, если поставить слип, то всегда получается 20/20. Можно, конечно, поймать пулю в голову и начать подключать джаваскрипт скроллы, клики в пустоту, чтобы занять это время "тольколишьнеслипами". Но зачем?
А как вы понимаете, сколько слип ставить? Есть ли требования производительности?