How to debug chained WebDriver `findElement` methods in Java

TLDR; split code across lines and breakpoint, and use browser dev tools to test the locators used.

Have you ever had an argument about fluent code? Discussions about “train wrecks” and “impossible to debug”?

WebDriver has the ability to chain findElement calls, and create such “train wrecks”. How do you debug it if you use it? (There is a summary video at the bottom of this post.)

Example:

WebElement element =
driver.findElement(By.id("a8")).findElement(By.name("pName8")).findElement(By.tagName("a"));

Each findElement returns a WebElement. Each WebElement has a findElement method. So we can chain them.

This allows us to find an element, then find a child of that element, and then find a child of that element.

Why?

That’s not really important right now since I’m discussing debugging, but …

  • might lead to easier to read code that a complicated CSS or XPath
  • we could store the results in variables and that might be easier to maintain
  • because… options. And having options is important.

But if something goes wrong… train wreck

“If something goes wrong it is impossible to debug.”

So I’ve been told.

But it doesn’t have to be impossible. Let’s consider some strategies.

Strategies

Intermediate Variables

If the WebElement returned from each call to findElement was stored in a variable then we could breakpoint each line, and add a ‘watch’ for each variable.

WebElement anchor = driver.findElement(By.id("a8"));
WebElement paragraph = anchor.findElement(By.name("pName8"));
WebElement finalAnchor = paragraph.findElement(By.tagName("a"));

This might also make it easier to see that we are looking for: anchor > paragraph > finalAnchor.

New Lines

What?

Yup, add a new line in the code so it looks like this:

WebElement element = driver.findElement(By.id("a8")).
                    findElement(By.name("pName8")).
                    findElement(By.tagName("a"));

Then we can add a breakpoint to each line.

You don’t get the benefit of being able to watch the early calls in the chain, but you can always use evaluate to run the code when breakpointed.

What about debugging locators?

And suppose we breakpoint it, and can see what goes wrong. How do we know what to change it to?

When debugging locators and location strategies we want to do that interactively in the browser. I tend to use the Firebug FirePath plugin, but we have similar features in Chrome and Firefox Browser Dev Tools.

e.g. in Chrome I can right click, ‘inspect’ and in the ‘Elements’ tab, can use find (ctrl+f) to search using Xpath, or CSS selectors.

@Test
public void findElementChaining(){
    WebDriver driver = new FirefoxDriver();

    driver.navigate().
    to("http://www.compendiumdev.co.uk/selenium/find_by_playground.php");
    
    WebElement element = driver.findElement(By.id("a8")).
                        findElement(By.name("pName8")).
                        findElement(By.tagName("a"));
    
    Assert.assertEquals("This is h paragraph text", element.getText());
}

And if I try the selectors in the example code above I can see that #a8 matches an anchor, which has no children. I can see that the chained By.name ([name="pName8"]) will never match anything, since it is the same element as the previous id locator.

Summary

  • It is important to have options with the code you write.
  • Learn to use the Evaluate Tool in IntelliJ
  • Split ‘chained’ method calls across new lines to add breakpoints
  • Using intermediate variables might make code easier to read
  • Test locators in the browser interactively using Browser Dev Tools

This entry was posted in Selenium Simplified Blog, WebDriver. Bookmark the permalink.

3 Responses to How to debug chained WebDriver `findElement` methods in Java

  1. Wayne Peacock says:

    A word of warning…

    I believe this will cause an exception if a parent element does not exist but will continue to try the next chained method. Maybe not in a compiled language (Java, C#) but I’m pretty sure I’ve come across this in PHP (and presumably would in other interpreted languages), where it creates a FATAL exception and aborts the entire test run. Instead you need to check the object is “not null or empty” before attempting findElement or any other WebElement method. I could be wrong and getting confused with something else as I’m writing this from memory.

    Therefore I suggest intermediate variables over new lines with interpreted (non-compiled) languages and checking you have an object in-between.

    • Alan says:

      I’ve not used a language where the situation you describe would occur. But if I ever encounter the situation then I’ll be able to corroborate.

      Thanks.

  2. Pingback: Testing Bits – 8/14/16 – 8/20/16 | Testing Curator Blog

Leave a Reply

Your email address will not be published. Required fields are marked *