Custom Keyword -> Is this good practice?

Archive
1

Hello everyone. Im not quite sure if this is a good practice to write keywords this way. I had some troubles to check a radio input element with the built in keyword. So i’ve written a custom keyword now to use a simple javascript click on that object in case the built in check keyword fails.

Im not that experienced with writing code in general and i have my doubts that my code is stable and it could potentially break.

Can someone tell me if this code is okay or am i missing some potential problems with using javascript click

/**
 * Custom Check keyword: Try to check with standard keyword. If check fails due to not clickable exception: Retry with JavaScript click()
 * @param to - Represents a TestObject
 */
@Keyword
def customCheck(TestObject to) {

	WebElement webElement = WebUiCommonHelper.findWebElement(to, 0)
	def isNotSelected = WebUI.verifyElementNotChecked(to,15)

	//Try to click with current test object if not selected
	try{
		if (isNotSelected) {
			WebUI.check(to)
		} else {
			println "Input element is already checked, therefore check action will not be executed"
		}

	} catch (Exception ex) {

		if (isNotSelected) {
			println("--- Standard check failed -> Catch block execution started: Check (click) via JavaScript ---")
			WebDriver driver = DriverFactory.getWebDriver()
			JavascriptExecutor executor = ((driver) as JavascriptExecutor)
			executor.executeScript('arguments[0].click()', webElement)
		}
		
		def isSelected = WebUI.verifyElementChecked(to,15)
		
		if (isSelected) {
			KeywordUtil.markPassed("Element was selected (checked) successfully.")
		} else {
			KeywordUtil.markFailed("Checking element failed!")
		}
	}
}
2

Daniel

Im not quite sure if this is a good practice to write keywords this way.

I have not picked over your code with a magnifying glass, but the answer to your question is a resounding “yes”. I do this ALL THE TIME. Pretty much all my interactions with page elements takes places through JavaScript calls. I have two fairly large Groovy-JS classes, one dedicated to making jQuery/dom calls, the other using native JavaScript/dom calls.

To be clear, what you have done is remove some of the disparity between webdrivers by asking and talking to the page directly about its state. That is generally a good thing and solves many problems like those you described.

Fear not! :sunglasses:

1 Like
3

I agree with Russ. We have made extensive use of Custom Keywords. When I write a custom keyword, I ask myself:

  1. Does it make the test more readable?
  2. Does it make our test automation more robust or reliable?
  3. Will the testers understand when and how to use it?
  4. Is it reusable across more than one test?
  5. Does it save development time?
1 Like
4

Instead of println please use KeywordUtil.logInfo. It will help write the message to all channels (GUI, log files).

2 Likes
5

Thank you all for your replies :slightly_smiling_face::+1:

6

Our implementation is almost ENTIRELY comprised of custom keywords. If you’re a fan of code reusability in general, or the Page Object Model in particular, custom keywords will almost certainly be the backbone of your project.

1 Like