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?
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.
2000% Stability Improvement From Only Using Explicit Waits
I worked with one client that had drastic instability in their automation with 30-40 failures out of every 100 tests.
Once, I helped them to remove ALL implicit waits from their code and only use Explicit waits, their test stability improved to ~2 tests failing out of 100.If you want to drastically stabilize your #test #automation by up to 2000%, simply make sure that you are not mixing implicit and explicit waits in #Selenium. Use explicit waits only. #development Click To Tweet
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
Disadvantages of each
- 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.
- the implicit wait sends a message to the “remote side” of the selenium WebDriver. The remote side of the selenium WebDriver is the part of selenium which is actually controlling the browser. What does the remote side do with the message? “It depends”. It depends on the operating system and on the browser and on the version of selenium. As far as I can tell there is no guarantee about the actual behaviour of a specific implementation. Meaning, we have no clue about how the implicit wait will behave (StackOverFlow)
- 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