Complete solution for Synchronization in Selenium WebDriver

David Tzemach

Posted On: September 26, 2022

view count11505 Views

Read time7 Min Read

While building a test automation project for a complex web application using Selenium WebDriver, we need to ensure that the test flow from beginning to end is maintained for reliable test automation.

When tests are executed, it is common that the application under test does not always respond with the same speed as you may expect when creating your tests leading to an “ElementNotVisibleException” error. For example, it might take a few seconds for a status message to appear, a window to open, or an element to be enabled.

You can handle these anticipated timing issues by synchronizing your tests to the actual delays in the web application under test to ensure that each test waits until your application is ready before performing a certain step that may fail, which will consume time again in debugging.

synchronizing your tests

Before diving into the solution, let’s cover the two main categories related to synchronization:

  1. Unconditional Synchronization– In this scenario, we specify timeout only. This means that we stop the test execution until a certain amount of time passes and then proceed further. For example, Thread.Sleep(7000); //Delay code execution for 7 seconds. The main disadvantage of this approach is the chance of unnecessary waiting time in the test execution even though the element is ready to be tested.
  2. Conditional Synchronization – We specify a condition along with the timeout value. The test framework waits to check for the condition and then decides to continue the test flow or come out if nothing happens.

In Selenium, we have implicit Wait and Explicit Wait conditional statements.

Synchronizing a test with an implicit wait

The Selenium WebDriver provides an implicit wait method to poll the Document Object.
Model (DOM) for a certain amount of time (works only for “FindElement” and “FindElements” statements). If WebDriver cannot find an element, it will wait a defined amount of time for the element to appear in the DOM.

When an implicit wait is implemented in tests, it is set with a default value of 0 and will be set for the whole life of the WebDriver object instance (applied immediately once we initiate the WebDriver).

If we set implicit wait, the find element will stop throwing an “ElementNotVisibleException” if the element is not found in the first instance; instead, it will wait for the timeout to expire and then proceeds further.

Before rushing and using it in your code, please note that using an implicit wait may slow down your test execution when an application responds as expected (no delays), as it waits for each element appearing in the DOM and will thus increase the overall time taken to complete execution flow.

Example using an implicit wait:

Note: Try to Minimize or avoid using an implicit wait in your tests and try to solve
synchronization issues with an explicit wait, which provides more control when compared with an implicit wait.

Summary:

  • The default polling time is 250 milliseconds (which means that WebDriver will search the element in DOM after every 250 milliseconds until it is found or the time specified ends).
  • An implicit wait can be set with different time frames (Hours, Minutes, Seconds Etc.).
  • Once set, the implicit wait is applied for the entire life of the WebDriver instance.
  • The implicit wait is declared with a single line (Usually on the setup function).
  • It is not suggested to use the implicit wait with a large time counter (And to be more productive, make sure you minimize your use of this method).
  • By design, the default delay value of implicit wait is 0 seconds.
  • When used, the implicit wait may slow down the test execution because it will wait for each element appearing in the DOM.
  • The implicit wait can be changed numerous times (No Limitation) through the session of the IWebDriver.

Synchronizing a test with an explicit wait

The Selenium WebDriver provides WebDriverWait and ExpectedCondition classes for Implementing an explicit wait. The ExpectedCondition class (present in the OpenQA.Selenium.Support.UI namespace in C#) provides a set of predefined conditions to wait for before proceeding further in the code. These two classes allow us to implement an explicit wait that we can use for synchronizing tests, which provides better control when compared with an implicit wait. Unlike an implicit wait, an explicit wait in Selenium will wait for certain conditions to occur. The conditions could be waiting for the presence of the web element, waiting for the element to become visible, etc.

It is recommended that you implement an explicit wait in cases where synchronization is needed, and the rest of the tests are working fine. Another advantage of explicit wait compared to implicit wait is that it will not wait for the MAX time-out before executing the test. If the condition for the explicit wait is satisfied, the wait condition is exited, and the execution will continue.

Another point worth mentioning is that when using explicit wait, it will not apply the time the driver instance is alive (similar to Implicit wait); explicit wait works only on the specific web element on which it is set, rather than on all the elements on the page. As I mentioned at the beginning, to define an explicit wait, Selenium WebDriver provides two classes that we will use during the implementation of an explicit wait:

The WebDriverWait Class

Provides the ability to wait for a condition during the code execution and validate if an element is present/visible/enabled/disabled etc.

The ExpectedCondition Class

Provides a set of common conditions (that we can use in the WebDriverWait command) that tell the driver to wait before proceeding to the next code based on a predefined condition.

Here are the major class members (Feel free to explore the remaining once):

Note: Starting from Selenium WebDriver version 3.11, the ExpectedCondition class is no longer available and has now moved to a new separate NuGet package (DotNetSeleniumExtras.WaitHelpers, respectively).

  • Step 1: Using NuGet, search for DotNetSeleniumExtras.WaitHelpers,
  • Step 2: Import that namespace into your class.

Import that namespace into your class

Let us look into different examples for using the above scenarios:

Difference between Implicit and Explicit wait

Difference between Implicit and Explicit wait

The WebDriverWait Class

Synchronizing a test with an explicit wait

The FluentWait is another variant in Selenium that lets you control the MAX amount of time the driver needs to wait for the defined condition to appear. This is done by defining the frequency at which the driver checks for the element before throwing ElementNotVisibleException.

The ExpectedCondition Class
When using the FluentWait instance, we can specify:

1. The MAX amount of time to wait for a condition.
2. The frequency with which FluentWait has to check the condition defined.
3. Ignore defined types of exceptions.

To put it simply, Fluentait looks for an element repeatedly at regular intervals until it reaches the MAX amount of time defined for its condition or until the object is found. FluentWait command is most useful when delays in the app can take longer durations to load (often occurs in Ajax applications).

FluentWaitis also known in the industry as “smart waits” because they don’t wait out the entire duration defined in the test. Instead, the test will execute as soon as the element is detected and the condition specified in .until (condition) method becomes ‘true’.

Code:

Watch this video to learn how to use Implicit Wait, Explicit Wait, and Fluent Wait in Selenium WebDriver and make your test case more reliable.

Author Profile Author Profile Author Profile

Author’s Profile

David Tzemach

The founder and owner of the Agile Quality Made Easy blog (25K followers). A platform that he uses for teaching and coaching others, sharing knowledge with people, and guiding them towards success while giving them the inspiration and tools to discover their own path.

Blogs: 55



linkedintwitter

Test Your Web Or Mobile Apps On 3000+ Browsers

Signup for free