There are two [main] things that contribute to the ‘flakiness’ of Selenium scripts; locators and synchronization. WebDriver introduced the idea of an ‘implicit wait’ which is a period of time that Se will poll the browser to see if the element that is trying to be located is now available and only at the expiry of it does it throw an exception. This is different than in Se-RC which immediately throws the exception.

In a webinar and follow-up blog post, Santi showed a clever way to add implicit waits to Se-RC at the [Python] driver level until (and we might never) they get back-ported to the Se Server code. By using this pattern I was able to add implicit waits into Py.Saunter.

The configuration for this is in conf/saunter.ini

<pre lang="shell">[Saunter]
use_implicit_wait: true
implicit_wait: 30

I actually almost didn’t add implicit waits into the code. If you think about it, what implicit waits do is let you be lazy with your synchronization. One of the key benefits of doing functional automation is you, the script creator, gain a greater understanding of the application being automated — including what constitutes synchronized. Implicit waits will happily accept a page flow that has had 3 new redirects injected into it, but explicit synchronization would fail — alerting you that something changed. Which just happens to the main benefit of running the scripts in the first place.

But if a script is known as flaky because of incorrect synchronization, it might not get run [often] and/or the results could be ignored which is actively against the purpose of automation (information) which is why the default for implicit waits is true.

An interesting experiment would be to run your scripts periodically with implicit waits disabled and put in explicit waits where ever implicit ones were saving your butt.