Skip to main content
blog title image

5 minute read - Selenium WebDriver FAQs Test Automation

How to Wait with WebDriver

Jun 30, 2020

How to synchronise on application state? How to Wait with WebDriver? Thread.sleep is not the answer, so what is?

Avoid Thread.sleep

The main thing we want to avoid is a Thread.sleep

If you do use Thread.sleep make it obvious what you are doing.

But do not rely on this for strategic automating.

    private void pauseToAllowVisibility() {
        }catch(Exception e){
            // ignore

For more information about Thread.sleep, check this blog post.


Waiting in WebDriver uses a WebDriverWait

new WebDriverWait(driver,10).
        // some ExpectedCondition to wait for

And the WebDriverWait can be assigned to a variable for re-use.


WebDriverWait wait = new WebDriverWait(driver,10);


I remember back in 2012 reading through the WebDriver code and finding a support class for ExpectedConditions class which exposes a bunch of static methods to save me having to write code.

ExpectedConditions contains a lot of common waiting conditions.

The ExpectedConditions class has a method waiting for a page title to contain some text.

new WebDriverWait(driver,10).

Creating Your Own ExpectedCondition

I can create and use my own ExpectedCondition classes:

new WebDriverWait(driver,10).
         until(new TitleContainsCondition("Selenium"));

This opens the driver to the page and waits until the Title contains the text “Selenium”.

And I would write code to support this i.e. my TitleContainsCondition class:

public class TitleContainsCondition implements ExpectedCondition {
    private String subMenuText;

    public TitleContainsCondition(final String subMenuText) {

    public Boolean apply(@Nullable WebDriver driver) {
        return driver.getTitle().contains(this.subMenuText);

Create Your Own ExpectedConditions

If I want a custom ExpectedConditions then I can create my own ‘factory’ class to return ExpectedCondition

new WebDriverWait(driver,10).

I do occasionally write a WaitFor Class to add application or non-standard conditions, since we test applications which are domain specific.

And the WaitFor would look like:

public class WaitFor {

    public static ExpectedCondition<Boolean> titleContainsCondition(String titleMustContain) {
        return new TitleContainsCondition(titleMustContain);


If I really wanted to I could use a WebDriverWait without a separate class.

    public void useInLineExpectedCondition(){
        new WebDriverWait(driver,10)
                    new ExpectedCondition<Boolean>(){
                        public Boolean apply(WebDriver driver) {
                            return driver.getTitle().startsWith("Selenium");

But I haven’t written any code like this for some time. If I use a wait then I would refactor it into a class of its own, or wrap it as a factory method e.g. on WaitFor


With Java 8 it is now possible to use waits in closure/lambda expressions.

    public void useViaLambdaExpressions(){

        WebDriverWait wait = new WebDriverWait(driver,10);
        ExpectedCondition<Boolean> titleStartsWithSelenium = mydriver ->
                            { return mydriver.getTitle().startsWith("Selenium");};


I rarely use this, but sometimes for adhoc experimentation or workarounds I do.

Historical Note

WebDriver initial implementation of waiting was much more basic.

e.g. here is some code from 2011(ish)

 new Wait("JS Page title did not change"){

     public boolean until() {   
             return driver.getTitle().startsWith("Selenium"));   
         }catch(Exception e){   
             // ignore not found exception   
         return false;   

Note: this post was originally written in 2011, hence the ‘historical note’ example, and updated on 20200603.

Wait Before or Wait After

In one of my early WebDriver training courses I had an exercise which involved waiting for an element to have clickability. It existed in the DOM, visible, and all other rendered event style isCondition()s. But when clicked on, it could not respond to events.

The initial approach involved trying to fix the problem at the point my code encountered it, i.e. when trying to click on it in the Page Object.

private void clickSubMenuItem(String subMenuText) {

    // insert lots of banging of head with failed automation code here
    // because the element below is visible but isn’t responding to clicks yet
    // can’t figure out how to detect if the element is responding to clicks
    // before I click on it because click doesn’t throw an exception
    // because it is there to click on

    String xpathExpression = //div[@class=\“GALD-WOBF\” and .=\“” + subMenuText + “\“]”;

The most robust solution for the automation issue by waiting, at the point my code puts the system into the state of unclickability, and waiting until it re-enters a state of clickability.

public void openClose() {
    WebDriverWait wait = new WebDriverWait(driver,20);
    ExpectedConditionFactory weCanSee = new ExpectedConditionFactory();

    By imageLocator = By.xpath(//div[.=\“”+ this.menuHeading + “\“]/../div/img”);

    // This is the wait I needed in the code above, but it only made sense here
    // do not consider it open or closed until the menu stops growing,

    By parentDiv = By.xpath(//div[.=\“”+ this.menuHeading + “\“]/../../..”);
    wait.until(weCanSee.elementStopsGrowing(parentDiv, driver));

Both waiting styles offer valid automation choices.

I found it interesting that I defaulted to the first style and that caused intermittency issues. I don’t think I’ve used the second style as much.

You can imagine more trade-offs associated with each style:

1st Style – Before Follow On Actions

  • Tests might go faster because, follow on actions may not require earlier waits as guard conditions
  • Page objects become more complicated because we have to remember to check for all guard conditions before taking action
  • Guard checking happens in multiple places
  • Risk of test intermittency because of emergent behaviour which we might find hard to debug

2nd Style – Immediately After triggering condition

  • Exit condition checks in single place
  • Less chance of exposing emergent behaviour as application keeps synchronised to a ‘good’ state
  • Leads to doSomething and doSomethingAndWait style methods

For some reason my approach to automation defaulted to the first style.

This post should act as a reminder to consider both styles.

Full Source

The full source for this is in my Webdriver Java FAQs project:


If you want to learn how to use Selenium WebDriver with Java then check out our online courses. We have course dedicated to Advanced Synchronisation, and one dedicated to the Support Classes.