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.
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("https://testpages.herokuapp.com/styled/find-by-playground-test.html");
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
