What is the difference between an implicit and explicit wait in Selenium WebDriver? This post will help you to understand the difference between an implicit and explicit wait once and for all!

Which should you use and why?

Warning: Do not mix implicit and explicit waits. Doing so can cause unpredictable wait times. For example, setting an implicit wait of 10 seconds and an explicit wait of 15 seconds could cause a timeout to occur after 20 seconds.

https://www.selenium.dev/documentation/webdriver/waits/

This ultimately means that if you have to use an explicit wait (defined here) even once, you cannot set an implicit wait (defined here) anywhere else in the code. Hence, if you need to check that an element is clickable, that the text of an element exists, or that a button is enabled… you cannot have a call to an implicit wait.

Use only an Explicit wait in Selenium for consistent behavior

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

Implicit Wait in Selenium

An implicit wait is to tell WebDriver to poll the DOM for a certain amount of time when trying to find an element or elements if they are not immediately available. The default setting is 0, meaning disabled. Once set, the implicit wait is set for the life of the session.

https://www.selenium.dev/documentation/webdriver/waits/

• 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

Explicit Wait in Selenium

• An explicit wait in Selenium 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 ExpectedConditions class that Selenium provides us. The driver 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

Implicit Wait

WebDriver driver = new FirefoxDriver();
driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));
driver.get("http://somedomain/url_that_delays_loading");
WebElement myDynamicElement = driver.findElement(By.id("myDynamicElement"));
// https://www.selenium.dev/documentation/webdriver/waits/

Explicit Wait

new WebDriverWait(driver, Duration.ofSeconds(3)).until(ExpectedConditions.elementToBeClickable(By.xpath("//a/h3")));

Differences in Default Wait Time

Implicit Default Timeout

0 sec

Explicit Default Timeout

.5 sec

Difference In Exceptions Thrown

Implicit Wait

• 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

Explicit Wait

• Explicit wait in Selenium throws a WebDriverTimeoutException, depending on your expected condition

Disadvantages of each

Implicit Wait

• An implicit wait in Selenium 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 in Selenium 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)

Explicit Wait

• 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 Implicit Wait 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.

Here is the difference between and explicit and an implicit wait from #selenium. The recommended approach is to use an explicit wait only. Learn more here Share on X

Case Studies

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 Share on X