My problem is, that at the GUI are two buttons with ident informations. It depends of the screen resolution which button is visible.
I tried to build my test case by using the “WebUI.clickImage” methode. Therefor I made a screenshot of the button and inserted the image at the TestObject settings.
That works very well when manually executing the TestCase or TestSuite. But when I execute it with jenkins over console mode I got the error
com.kms.katalon.core.exception.StepFailedException: Unable to click on image (Root cause: java.lang.Exception: Cannot recognise image on screen)
My next solution is to check which button is visible and only click on that. But I have no idea how to handle this.
I tried to save the result of “findTestObject” in a List, but failed with casting or other errors.
In particular, if you can share the HTML for the buttons involved, it would be much easier to provide a solution. The two buttons will almost definitely be uniquely identifiable in the HTML based on resolution.
So first, I think that the <span> element that you’ve got highlighted there isn’t really the element you want. You should target the ancestor <a> element instead. Next, I have a couple of questions:
1.) Does an element for both buttons exist in the HTML simultaneously, and only one of them is visible at any given time based on screen resolution? Or do you only ever see one element?
2.) In the above screenshots, are these looking at two different buttons? Or are they screenshots of the same button under different screen resolutions?
ad 1: I checked this by using ChroPath and checked it by using following xpath:
//span[starts-with(@id,‘pp-toolbar-create-’) and contains(@id,‘btnWrap’)][count(. | //[@class = ‘x-btn-wrap’]) = count(//[@class = ‘x-btn-wrap’])]
Nice. So notice in the screenshot for ad 1 that one of them has a style attribute, while the other doesn’t. Try adding this as a predicate to your xpath. So it would look something like:
//span[starts-with(@id,‘pp-toolbar-create-’) and contains(@id,‘btnWrap’) and @style]
I’m not sure whether this identifies the non-visible button or the visible one, but in either case, this will make it a unique identifier.
That works in chroPath, but at execution time in Katalon I get the following error:
Test Cases/Record specific/Create new Record FAILED.
Reason:
com.kms.katalon.core.exception.StepFailedException: Unable to click on object (Root cause: java.lang.IllegalArgumentException: Object is null)
at com.kms.katalon.core.keyword.internal.KeywordMain.stepFailed(KeywordMain.groovy:36)
at com.kms.katalon.core.webui.keyword.internal.WebUIKeywordMain.stepFailed(WebUIKeywordMain.groovy:65)
at
Did you change the name or location of your Test Object, or the path to it in your test code? That error usually occurs when the Test Object can’t be found at the specified location in the Object Repository.
and now on posting I see, I forgot the folder name “Create Record/”
Now I got error like
Test Cases/Record specific/Create new Record FAILED.
Reason:
com.kms.katalon.core.exception.StepFailedException: Unable to click on object ‘Object Repository/Create Record/Create_Btn’ (Root cause: org.openqa.selenium.ElementNotInteractableException: Element could not be scrolled into view
I tried to focus or scroll to the element
WebUI.focus(findTestObject(‘Create Record/Create_Btn’))
WebUI.scrollToElement(findTestObject(‘Create Record/Create_Btn’), 5)
2.) Try using JavaScript to scroll to the element instead:
// Use code from above, but execute this JS instead:
js.executeScript("arguments[0].scrollIntoView(true);", element);
With this one, you can change the boolean value to true/false in the scrollIntoView() method to try and scroll the element to the top/bottom of the window, respectively.
3.) Try maximizing the browser window before the script tries to click on the button, if you aren’t already. I would try doing this manually first, to see if it makes any difference. Just run the script in debug mode with a breakpoint at the WebUI.click(findTestObject(‘Create Record/Create_Btn’), FailureHandling.STOP_ON_FAILURE) line. If it does work, I can offer you a Desired Capability that will maximize the browser window automatically when the script runs.
That’s a very technical phrase only used by fully qualified test engineers and only in the most appropriate circumstances. I guess this is one of those circumstances.