I was in a vendor talk by Jim Holmes of Telerik[1] last week where he was showing how to do some simple things in both his product and Selenium. One of things was the use of implicit waits. I mentioned to him afterwards that I actually try to avoid them in my code. This was an unexpected comment to him which means I need to write about my current thinking.
Implicit waits are where an upper bounded polling action happens looking for an element in the page before throwing an exception saying it wasn’t there. This would seem like a good thing as you will have less scripts failing due to synchronization problems which in turn means that you have to spend less time maintaining and repairing scripts.
But.
What it is actually doing is masking synchronization problems.
When I am writing scripts I want the synchronization to be as tight as absolutely possible. Taking a line from the Tao of Python, Explicit is better than implicit. Disabling implicit waits in an existing script set often leads to two things
- Wholesale breakage due to places you were being lazy with the synch
- Some bug reports with the application because you now notice which things are appearing when, in what order and in how long
One of the knocks against automation is that, unlike humans, it doesn’t have emotions. Confusion, frustration, etc. What you can teach your scripts to be though is impatient. And you do that by disabling implicit waits.
Writing automation with explicit waits is without question more work and forces you to not take convenient shortcuts. The resulting code however will be tighter, run more efficiently and be half a step closer to the end-user’s perspective than without.
All that said, when automating against a moving target implicit waits can save the day. The trick though is to continually lower the wait duration until it is off. Fixing problems as you go.
[1] It was actually billed as a vendor talk and is not a slag on Jim’s other talk at the conference which was very un-vendor-like
Post a Comment