Some (More) Simple Selenium Helper Methods

Are there parts of Selenium automation that scare you?  No? Well there are parts that scare me, and one of them is Advanced User Actions.  It’s very powerful and useful, but I never feel comfortable implementing User Actions without lots of Googling first to make sure I’m doing it right.

So I cheat, and look it up once and then put that dreadful code into a helper method so I never (?) have to look it up again!  If I later find a better way to do it, I can just update the helper method itself, and then all that newfound brilliance will trickle down to the test cases that use that method. I call it (drum roll please) moveToElementAndClickCss():

public void moveToElementAndClickCss(String cssString) {
	new WebDriverWait(driver, 20).until(ExpectedConditions.visibilityOfElementLocated(By.cssSelector(cssString)));
	new WebDriverWait(driver, 20).until(ExpectedConditions.elementToBeClickable(By.cssSelector(cssString)));
	Actions builder = new Actions(driver);
	Action moveAndClick = builder.moveToElement(driver.findElement(By.cssSelector(cssString)))
	.click()
	.build();
	moveAndClick.perform();	
}

   

We pass a css element path as the argument and let the method code take care of moving to that element and clicking it.

I of course have another one called moveToElementAndClickXpath(), which you should be able to infer from the css version.  These methods are very simple, but again help to speed up test case design and make the resulting tests more maintainable and easier to read.

Some Simple Selenium Helper Methods

I just wanted to pass along some Selenium/WebDriver helper methods that I used a great deal in a recent project. This first series are my ‘tryBy’ helpers, which simply return a boolean value depending on whether or not the specified element exists. It’s handy for when you want to do some quick content checks using XPATH or CSS, but don’t want to have everything grind to a halt if the element in question is not found. These methods use a simple try/catch loop to bypass the exception and simply return a FALSE if the element is not there.

Here’s the code for tryByXpath():

	/**
	 * This method lets you test for the existence of an element.
	 * 
	 * @param xpath = xpath selector text
	 * @return TRUE if xpath element isDisplayed, false with no error if not
	 */
	public boolean tryByXpath(String xpath) {
		try {
			new WebDriverWait(driver, 10).until(ExpectedConditions.presenceOfElementLocated(By.xpath(xpath)));
			new WebDriverWait(driver, 10).until(ExpectedConditions.visibilityOfElementLocated(By.xpath(xpath)));
			return true;
		} catch (TimeoutException e) {
			report.report("Xpath element not found: " + xpath);
			return false;
		}
	}

And here’s the same idea for CSS, aptly named tryByCss():

	/**
	 * This method lets you test for the existence of an element.
	 * 
	 * @param css = css selector text
	 * @return TRUE if css element isDisplayed, false with no error if not
	 */
	public boolean tryByCss(String css) {
		try {
			new WebDriverWait(driver, 10).until(ExpectedConditions.presenceOfElementLocated(By.cssSelector(css)));
			new WebDriverWait(driver, 10).until(ExpectedConditions.visibilityOfElementLocated(By.cssSelector(css)));
			return true;
		} catch (TimeoutException e) {
			report.report("Xpath element not found: " + css);
			return false;
		}
	}

And lastly, tryByLinkText:

	/**
	 * This method lets you test for the existence of an element.
	 * 
	 * @param text = link text selector text
	 * @return TRUE if link text element isDisplayed, false with no error if not
	 */
	public boolean tryByLinkText(String text) {
		try {
			return driver.findElement(By.linkText(text)).isDisplayed();
		} catch (NoSuchElementException e) {
			report.report("Xpath element not found: " + text);
			return false;
		}
	}

The pattern is simple and there’s nothing tricky going on here, but creating helpers like these can really help save you a lot of time when writing your tests, and also helps to make your test code much easier to read.

For a small test suite, you can put these helpers in the test class itself. In a larger suite with multiple test classes, put them in a parent or abstract class which will then make them available to all child classes in which you write your tests.

In use, typical scenarios will look a lot like this:

boolean closeButton = tryByXpath("//*[text()='close']");
if (!closeButton) { report.report("problem with closeButton"); }

In that example we’re just checking to see if the Close Button exists, using XPATH. If it’s not there, we report the problem and move on. If it’s there, we move on and can use the information at the end of the test by stringing all the booleans together:

return closeButton && assetIcon && (etc. etc.)

The method calling this test method could then fail the test case if any of the content is missing, or pass it if all the content is there. You could also use it directly as a part of a JUnit assertion or any other way you like.