Over a million developers have joined DZone.

How to Debug Chained WebDriver 'findElement' Methods in Java

DZone 's Guide to

How to Debug Chained WebDriver 'findElement' Methods in Java

Want to know how to debug a chained WebDriver findElement in Java? In short, split code across lines and breakpoint and use browser dev tools to test the locators used. Read on for more info.

· Java Zone ·
Free Resource

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.)


WebElement element =

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.


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

  • might lead to easier to read code than 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.


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


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

WebElement element = driver.findElement(By.id("a8")).

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.

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


    WebElement element = driver.findElement(By.id("a8")).

    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.


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

css ,firebug ,firefox ,breakpoint ,dev ,plugin ,browser ,css selectors ,id ,train

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}