ahmelevsky

 

А можно что-нибудь из массы?

Смотрите, какая проблема в слипах - да в общем-то никакой, просто они работают либо дольше чем нужно либо короче. В первом случае мы немножко проигрываем во времени, во втором - валимся. Периодическое возникновение второй ситуации и есть та самая нестабильность, о которой, не исключено, пишет автор топика. 

Ситуации "из массы" приводить не нужно, это я так написал. Если мы говорим про ожидание того или иного состояни элемента (а о других ситуациях тут говорить не вижу смысла), слип никак не лучше, просто иногда не получается/невозможно написать ожидание.

 

 

Скажите, как я могу чет-то из селениума дождаться, когда по элементу можно будет кликнуть? isDisplayed уже возвращает true, present и visibility также возвращают true. Т.е. в классе WebDriverWait все возврашает true (я все перепробовал), он бесполезен.

 

Вы все-таки приведите сообщение об ошибке, так будет легче делать предположения.

Для часто обновляющихся интерфейсов я не знаю более эффективного способа борьбы со StaleElementReferenceException, чем повторить попытку.
 
У меня есть достаточно "универсальное" решение этой проблемы, при помощи обёртки, которая пытается повторно найти потерянные элементы.
 
Исходники тут: https://github.com/b...iver-extensions
Maven: http://search.maven....pper|1.0.41|jar
 
Пользоваться несложно, нужно просто "обернуть" драйвер:

WebDriver driver = new FirefoxDriver(); // или какой-нибудь другой
driver = new StaleTolerantWrapper(driver).getDriver();

и дальше работать с этой обёрнутой версией.

 

Ограничение: не поддерживается повторный поиск "пропавших" элементов, найденных операцией findElements (которая целый список возвращает), повторно находятся только элементы, которые были найдены при помощи findElement, в том числе по цепочке, внутри других элементов.

Спасибо, Алексей, очень полезная версия драйвера.

Попробуйте привязаться (через xpath) к другому атрибуту/атрибутам элемента. Причем, конечно придется использовать contains. Например: 

 By.xpath("//input[contains(@onselect,'mobjApp.Events_TextSelection)"]

Только проверьте, что по этому xpath находится только один элемент.

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

 

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

Это не догма - исключений масса.

 

А можно что-нибудь из массы?

Смотрите, какая проблема в слипах - да в общем-то никакой, просто они работают либо дольше чем нужно либо короче. В первом случае мы немножко проигрываем во времени, во втором - валимся. Периодическое возникновение второй ситуации и есть та самая нестабильность, о которой, не исключено, пишет автор топика. 

Ситуации "из массы" приводить не нужно, это я так написал. Если мы говорим про ожидание того или иного состояни элемента (а о других ситуациях тут говорить не вижу смысла), слип никак не лучше, просто иногда не получается/невозможно написать ожидание.

 

Подобный код не приносит железного результата, выбирает через раз:

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

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