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

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.