Существуют ли потенциальные недостатки сверхкороткой продолжительности опроса в Fluent Wait в Selenium?

При использовании FluentWait в Selenium можно настроить продолжительность опроса FluentWait.

Насколько я знаю, это частота проверки существования элемента, например

Таким образом, если тайм-аут составляет 3 секунды, а заданная продолжительность опроса составляет 250 миллисекунд, драйвер будет проверять наличие элемента 12 раз, прежде чем в конечном итоге выдаст исключение, когда он проверит элемент в 13-й раз.

Насколько я понимаю и по этой логике, уменьшение продолжительности опроса повышает производительность скрипта, потому что он будет проверять наличие элемента больше раз.

Ниже вы можете найти мою реализацию FluentWait

public static void waitForElementWithDuration(By locator, Duration duration) {
        FluentWait<org.openqa.selenium.WebDriver> wait = new FluentWait<>(Base.driver);
        wait.withTimeout(duration)
            .pollingEvery(ConfigurationManager.DEFAULT_POLLING_DURATION)
            .ignoring(NoSuchElementException.class, ElementClickInterceptedException.class)
            .until(ExpectedConditions.and(
                   ExpectedConditions.presenceOfElementLocated(locator),
                   ExpectedConditions.elementToBeClickable(locator)));
}

Я думаю о сокращении продолжительности опроса по умолчанию в моем классе менеджера конфигурации (сейчас она составляет 250 мс). Будут ли какие-либо потенциальные недостатки, если я установлю продолжительность опроса на 10 мс? Поскольку поток, который я автоматизирую, довольно длинный и его нужно повторять много раз, реализация более короткой продолжительности опроса значительно сократит общее время, необходимое для запуска тестов.

Я работаю инженером по автоматизации тестирования уже 1,5 года, поэтому я все еще новичок и был бы признателен за помощь более опытных инженеров по автоматизации тестирования.

1/2 секунды - это уже довольно мало. Помните, что потребуется определенное время, чтобы проверить DOM, чтобы произошло выброшенное исключение, чтобы драйвер проверил исключение и проигнорировал его... также есть время в пути между браузером-> драйвер-> ваш код и обратно.. Я не знаю, как долго это будет, но в какой-то момент у вас будет не прирост скорости вообще, а, может быть, даже замедление.

pcalkins 24.01.2023 21:11

Большое спасибо за Ваш ответ! Можете ли вы расширить (или предоставить некоторые ресурсы, которые я мог бы проанализировать и прочитать) относительно потенциального замедления? Я осознаю, что для выполнения проверок требуется время, и что сократить это время невозможно, с чем я согласен. Фреймворк, который я разрабатываю, управляется данными, поэтому может быть до 1000 комбинаций в 1 потоке и около 50 локаторов на поток, поэтому, по моим расчетам, это изменение (с 250 мс до 10 мс) сделает каждый запуск 1000 комбинаций 2,8 часа. Быстрее.

Bozidar Kostic 24.01.2023 22:24

каждое ожидание будет длиться ровно столько времени, сколько необходимо для выполнения ожидаемого условия. Только если элемент никогда не будет найден, потребуется полный период ожидания. Таким образом, вы можете сбрить несколько миллисекунд, но это было бы непредсказуемо... это сон внутри цикла, но фактический опрос занимает определенное время... У меня нет никаких ресурсов для цитирования, вы должны просто сделайте свои собственные проверки / тесты скорости, чтобы увидеть, в какой момент у вас есть убывающая отдача.

pcalkins 24.01.2023 22:49

если основной проблемой является скорость, вы можете рассмотреть возможность использования пар браузер/драйвер. Или, если вы можете справиться с этим, используйте что-то более легкое, например HTMLUnit, и постройте его.

pcalkins 24.01.2023 23:01

К сожалению, многопоточность невозможна, поскольку это среда тестирования интеграции E2E, и некоторые потоки необходимо выполнять по порядку из-за конкретных потребностей продукта. Это основная причина, по которой я рассматриваю другие возможности, чтобы сократить время. Я ценю время, потраченное на ответы на мои вопросы и ответы на мои комментарии!

Bozidar Kostic 24.01.2023 23:21
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
1
5
81
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

FluentWait

Согласно документации, FluentWait является реализацией интерфейса Wait, время ожидания и интервал опроса которого могут быть настроены на лету. Каждый экземпляр FluentWait определяет максимальное время ожидания условия, а также частоту проверки условия. Кроме того, пользователь может настроить ожидание для игнорирования определенных типов исключений во время ожидания, таких как NoSuchElementExceptions при поиске элемента на странице.

Пример использования:

// Waiting 30 seconds for an element to be present on the page, checking
// for its presence once every 5 seconds.
Wait<WebDriver> wait = new FluentWait<WebDriver>(driver)
    .withTimeout(Duration.ofSeconds(30L))
    .pollingEvery(Duration.ofSeconds(5L))
    .ignoring(NoSuchElementException.class);

WebElement foo = wait.until(new Function<WebDriver, WebElement>() {
  public WebElement apply(WebDriver driver) {
    return driver.findElement(By.id("foo"));
  }
});

В документации также упоминается возможный компромисс:

Этот класс не дает никаких гарантий безопасности потоков.


опроскаждый

Опять же, согласно документации, pollingEvery устанавливает, как часто должно оцениваться условие. В случаях использования в реальном времени интервал может быть больше, поскольку стоимость фактической оценки функции условия не учитывается. Однако интервал опроса по умолчанию составляет DEFAULT_WAIT_DURATION, который определяется как 500L:

DEFAULT_SLEEP_TIMEOUT


Этот вариант использования

Учитывая вышеупомянутые аспекты, я не вижу никаких проблем с уменьшением polling duration от значения по умолчанию до 10ms или даже 5ms, что уменьшило бы время выполнения фреймворка. Единственная проблема заключается в том, что WebDriver не является потокобезопасным.

Я удалил свои предыдущие комментарии, чтобы не вызывать путаницы, потому что проблема, с которой я столкнулся, была не из-за уменьшения продолжительности опроса, теперь все работает отлично! Спасибо за помощь!

Bozidar Kostic 25.01.2023 14:08

Другие вопросы по теме