Confused about all of the different Selenium Webdriver Timeouts? This post will help you to understand the difference between an Explicit and Implicit Wait.
Which should you use and why?
Table of Contents
Based on recommendations from Selenium community…
You should only use an Explicit Wait
I would just recommend that you take a read of this comment from Jim Evans, the C# Selenium bindings maintainer.
Don’t mix implicit and explicit waits. Part of the problem is that implicit waits are often (but may not always be!) implemented on the “remote” side of the WebDriver system. That means they’re “baked in” to IEDriverServer.exe, chromedriver.exe, the WebDriver Firefox extension that gets installed into the anonymous Firefox profile, and the Java remote WebDriver server (selenium-server-standalone.jar).
Explicit waits are implemented exclusively in the “local” language bindings. Things get much more complicated when using RemoteWebDriver, because you could be using both the local and remote sides of the system multiple times.
This is how that would work: local code -> Java remote server -> local Java language bindings on the remote server -> “remote” component like the Firefox extension, chromedriver.exe or IEDriverServer.exe. It’s even more complex in the grid case, since there could be other hops in between.
Thus, when you try to mix implicit and explicit waits, you’ve strayed into “undefined behavior”. You might be able to figure out what the rules of that behavior are, but they’ll be subject to change as the implementation details of the drivers change. So don’t do it.
You shouldn’t be experiencing “hangs” when an element can’t be found if you’re not using implicit waits. The driver should throw a NoSuchElementException immediately.
So, that’s reason why I never use an implicit wait and I recommend my students why not to use it.
- If you use an Explicit Wait even once and you follow Jim’s recommendation, it means that you can’t use an ImplicitWait any more.
- Otherwise, you will be mixing waits.
- Therefore, you shouldn’t ever use an Implicit Wait. I’ve never needed to use it in my test automation.
Difference In Definition
- Tell WebDriver to poll the DOM for a certain amount of time. This is literally using the ImplicitWait property that Selenium WebDriver offers.
- Waits for an element to exist in the DOM, that’s it. Cannot tell if an element is hidden for example.
- Only needs to be configured once
- Less flexible
- This is the code that you write to wait for a certain condition to occur before proceeding. You can use the WebDriverWait class, Thread.Sleep, or write your own from scratch.
- Recommended way to wait in your tests
- The easiest way to use this is through the WebDriverWait class that Selenium provides us
- Selenium will try an action repeatedly (is element visible, is element present, is button clickable…) until the action can be accomplished or an exception is thrown
Differences in Code
Differences in Default Wait Time
Implicit Default Timeout (sec) – 0
Explicit Default Timeout (sec) – .5
Difference In Exceptions Thrown
- Throws a NoSuchElementException when the element is not present in the DOM
- Throws a ElementNotVisibleException when element is present in the DOM, however, it is hidden and cannot be interacted with
- Throws a WebDriverTimeoutException, depending on your expected condition
- An implicit wait only works with elements that exist on the page. If the element is hidden in the DOM, an implicit wait will never work. So you will be forced to use an explicit wait to synchronize on that element. An in depth example is here. Also, an element may be present in the DOM, but not fully loaded. ImplicitWait will still return because that element is present.
- You need to use more lines of code to create an explicit wait
Food for thought
One possibly useful use case of an ImplicitWait is to use it with running on a service like Sauce Labs or Browser Stack. Because Implicit Wait doesn’t use the network to execute commands, it might actually be a performance enhancement and flakiness removal measure. Since an ImplicitWait forces the driver to poll rather than sending HTTP requests from the code to the driver, this can, in theory, reduce latency.
This HAS NOT been proven or documented anywhere. However, this is a theory that is floating around between myself and some other Solution Architects. We need data to back up this theory!
But if you’re willing to try it, give it a shot and let me know in the comments below if this helps you with your automation in the cloud.I learned the difference between and explicit and an implicit wait from #selenium. I finally know when to use one over the other! Click To Tweet