При использовании 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 года, поэтому я все еще новичок и был бы признателен за помощь более опытных инженеров по автоматизации тестирования.
Большое спасибо за Ваш ответ! Можете ли вы расширить (или предоставить некоторые ресурсы, которые я мог бы проанализировать и прочитать) относительно потенциального замедления? Я осознаю, что для выполнения проверок требуется время, и что сократить это время невозможно, с чем я согласен. Фреймворк, который я разрабатываю, управляется данными, поэтому может быть до 1000 комбинаций в 1 потоке и около 50 локаторов на поток, поэтому, по моим расчетам, это изменение (с 250 мс до 10 мс) сделает каждый запуск 1000 комбинаций 2,8 часа. Быстрее.
каждое ожидание будет длиться ровно столько времени, сколько необходимо для выполнения ожидаемого условия. Только если элемент никогда не будет найден, потребуется полный период ожидания. Таким образом, вы можете сбрить несколько миллисекунд, но это было бы непредсказуемо... это сон внутри цикла, но фактический опрос занимает определенное время... У меня нет никаких ресурсов для цитирования, вы должны просто сделайте свои собственные проверки / тесты скорости, чтобы увидеть, в какой момент у вас есть убывающая отдача.
если основной проблемой является скорость, вы можете рассмотреть возможность использования пар браузер/драйвер. Или, если вы можете справиться с этим, используйте что-то более легкое, например HTMLUnit, и постройте его.
К сожалению, многопоточность невозможна, поскольку это среда тестирования интеграции E2E, и некоторые потоки необходимо выполнять по порядку из-за конкретных потребностей продукта. Это основная причина, по которой я рассматриваю другие возможности, чтобы сократить время. Я ценю время, потраченное на ответы на мои вопросы и ответы на мои комментарии!
Согласно документации, 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
:
Учитывая вышеупомянутые аспекты, я не вижу никаких проблем с уменьшением polling duration
от значения по умолчанию до 10ms
или даже 5ms
, что уменьшило бы время выполнения фреймворка. Единственная проблема заключается в том, что WebDriver не является потокобезопасным.
Я удалил свои предыдущие комментарии, чтобы не вызывать путаницы, потому что проблема, с которой я столкнулся, была не из-за уменьшения продолжительности опроса, теперь все работает отлично! Спасибо за помощь!
1/2 секунды - это уже довольно мало. Помните, что потребуется определенное время, чтобы проверить DOM, чтобы произошло выброшенное исключение, чтобы драйвер проверил исключение и проигнорировал его... также есть время в пути между браузером-> драйвер-> ваш код и обратно.. Я не знаю, как долго это будет, но в какой-то момент у вас будет не прирост скорости вообще, а, может быть, даже замедление.