Skip to main content

May 24, 2011 - 3 minute read - Selenium Simplified Blog WebDriver

When automating, do you wait before or after the event?

As I worked on the code for my “migrating to selenium 2.0” workshop at Tony Bruce's Skills Matter event recently. One of my automation challenges involved waiting for an element to have clickability. It existed in the DOM, visible, and all other rendered event style is_Condition()s_. But when clicked on, it could not respond to events.

For a reason of bias, I spent far too many minutes banging my head against the automation wall. My brain insisted on 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 + “"]";

I solved 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 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, and maybe I won’t get stuck too long on a synchronisation problem again.

You will need a Github account to comment. Or you can contact me with your comment.

I reserve the right to delete spam comments e.g. if your comment adds no value and its purpose is simply to create a backlink to another site offering training, or courses, or etc.