Hey, Katalon.
Could you please develop IsElement… keywords (just returning true or false) to be used instead of those verifyElement… keywords that are totally useless most of the time because they are throwing exception even if FailureHandling.OPTIONAL is used? Thanks in advance!
( i.e. [WebUI] Verify Element Visible - #11,
etc., etc., etc. )
Like I told you elsewhere, you’re mistaken.
Understand there are MANY people using these APIs - successfully. If there was something wrong I think we’d see more bug postings.
No, it’s NOT. If an element is NOT PRESENT, this will make Verify Element Visible throw StepFailedException ( element is not found) EVEN if FailureHandling.OPTIONAL is used. That’s just another example of pure insanity of all these Katalon “verifyElement…” keywords, which makes them totally useless most of the time.
That is not true. Tested with KSE 8.0.1.
In the following code, we’re trying to check visibility on the element with id=barX on THIS webpage. It does NOT exist. However, there is an element with id=bar - so you can try the code for success and failure yourself.
WebUI.navigateToUrl("http://forum.katalon.com/t/webui-verify-element-visible/16765")
WebUI.waitForPageLoad(5)
TestObject to = makeTO("#barX")
WebUI.comment('Check NAV bar is visible')
WebUI.verifyElementVisible(to, FailureHandling.OPTIONAL)
WebUI.comment('Continuing...')
Like the documentation says, FailureHandling.OPTIONAL sets the step to WARNING status if the element is not found.
Note there is no StepFailedException above.
I understand you’re frustrated about something but I think you’re misinformed and confused as to what’s going on. Either way, your anger is completely misdirected and unwarranted.
Advice: Place your failing code complete with error messages in a new post so we can take a look. That way you might solve your problem instead of raising your blood pressure even more.
Yes, it IS TRUE in Katalon 7.9.1 (the element is not present, the code below is used just to see how verifyElementVisible REALLY works)
if( WebUI.verifyElementVisible(findTestObject('DM/Admin/Deals/Deal/Flags/td_Payments enabled'), FailureHandling.OPTIONAL) ) {
println "visiblle"
//return
}else{
println "not visiblle"
}
2021-06-08 14:51:57.717 INFO c.k.k.core.webui.driver.DriverFactory - proxyInformation = ProxyInformation { proxyOption=NO_PROXY, proxyServerType=HTTP, username=, password=********, proxyServerAddress=, proxyServerPort=0, executionList="", isApplyToDesiredCapabilities=true }
2021-06-08 14:52:28.744 INFO c.k.k.c.webui.common.WebUiCommonHelper - Unable to find the element located by ‘By.xpath: //[(text() = ‘Payments enabled’ or . = ‘Payments enabled’)]’. Please recheck the objects properties to make sure the desired element is located.
2021-06-08 14:52:29.274 WARN c.k.k.core.keyword.internal.KeywordMain - Web element with id: ‘Object Repository/DM/Admin/Deals/Deal/Flags/td_Payments enabled’ located by '//[(text() = ‘Payments enabled’ or . = ‘Payments enabled’)]’ not found (Root cause: com.kms.katalon.core.exception.StepFailedException: Web element with id: ‘Object Repository/DM/Admin/Deals/Deal/Flags/td_Payments enabled’ located by ‘//*[(text() = ‘Payments enabled’ or . = ‘Payments enabled’)]’ not found
So you found a bug in an old version? How is that helpful and how does it warrant your tirade?
I was just replying to ThanhTo’s comment ( posted on Feb 18, '19 4:59 AM) Was he using the latest version (8.0.1. that’s just been released recently) at that time? ))
Who knows. I tried 7.9.0 too - works here.
Technically, you are right, Russ. The problem is my managers do not like seeing those traces anyway. So I have no choice but to develop my own functions to avoid it. What is wrong with having the keywords that just return true or false?
I do that, too. There is very little reported by a running script that is useful to me.
On the face of it, nothing. However, the verify* APIs (and their wait* siblings) have more than one job to do (purists would say that’s a problem in and of itself). To do that, you have to manage the results using Failure Handling.
I’m not a fan, but that’s how they work.
Your biggest problem is to (re)educate your manager(s). 
I cannot agree more, Russ! (I wish I were as good at (re)educating my manager(s) as you are at handling “difficult customers” like myself)) On the other hand, purists would say that it’s not the best approach to build your logic on handling Failure that is expected to happen each time. Thank you for your comments.
I’d just like to be more specific and give a simple example where it could be useful. Suppose, you need a checkbox to be checked but at the beginning you don’t know whether it’s checked or not. With IsElementChecked, that would be very easy and now try to do the same with verifyElementChecked that throws exceptions.
Just catching up on this thread…
I would suggest creating your own utility class here, and do the checks in exactly the way you want using Selenium, which is what Katalon does behind the scenes anyway (i.e. not logging warning messages, just returning a boolean value).
Here’s a stubbed out one in Java that you could use, as an example. I do this sort of thing all the time, and I’m sure others do as well:
public class ElementUtil {
public static boolean isElementPresent(TestObject testObject, int timeout) {
try {
List<WebElement> elements = WebUiCommonHelper.findWebElements(testObject, timeout);
return elements.size() > 0;
} catch (Exception e) {
return false;
}
}
public static boolean isElementChecked(TestObject testObject, int timeout) {
try {
WebElement element = WebUiCommonHelper.findWebElement(testObject, timeout);
return element.isSelected();
} catch (Exception e) {
return false;
}
}
public static boolean isElementVisible(TestObject testObject, int timeout) {
// you get the idea...
}
}
There is one argument against catching any exceptions and just returning false. Lets say that you call isElementChecked(), and you get a false. Was it false because the checkbox wasn’t checked? Or was it false because the element couldn’t be found? You’ll have to mess with the catch statements to handle these scenarios.
As a side note: I agree with you @gdearest07 when you say
In my personal opinion, in this case, the framework you are working with should simply return the state of the page. Then it’s up to you to decide what to do with that information (fail your test, log it, use it in a conditional statement, etc.). This is why I tend to write my own Custom Keywords to do everything in Katalon.
Thank you, Brandon! That’s very similar to what I’ve being doing when it is needed. And that’s why I think that it would be great if IsElement… keywords (just returning true or false) were developed by Katalon in addition to the existing verifyElement… keywords.
Believe it or not, the history of the WebUI.waitForElement____() and WebUI.verifyElement____() families of methods goes way back, and the implementation has never been great in my opinion, at least not for the type of custom scripting that you’re talking about. I have several very old topics on it.
I think the biggest thing that is missing from this conversation is that most of the WebUI methods are tailored to work out-of-the box with scripts from Katalon Recorder. I think there is reluctance to change/add to these built-in keywords for several reasons.
1.) Changing the implementation this late in the game could potentially be catastrophic for teams that are using (and paying for) Katalon studio. They are kinda “stuck” with the current implementation.
2.) Adding a family if WebUI.isElement____() methods wouldn’t risk breaking any existing code, but it just doesn’t make sense in the context of a recorded script. Like, if you’ve ever recorded a script yourself, or at least looked at an example one, it’s basically just a series of WebUI calls, and no variable assignments. So doing something like:
def checked = WebUI.isElementChecked(...)
doesn’t make a lot of sense to a recorded script. It’s not actionable, where “waitFor” and “verify” are.
However, I don’t think these are arguments against the Katalon team addressing your question. I agree that it should be considered at least. But at the end of the day, you’ll find hundreds of examples of where the built in keyword doesn’t do exactly what you want it to, so you may as well get used to implementing things yourself 