Hello,
Please clarify what the longest expression is accepted to compare?
I need to compare urls.
885699 chracters. Seems to much…
WebUI.verifyMatch() / WebUI.verifyNotMatch() sometimes fails, sometimes passes when it should be failed.
Please comment on the use case.
Thank you!
Well … before to get the discussion started, what kind of URL’s that long are you trying to test?
Something does not fit with my knowledge, but I may be old …
@anon46315158 the URLs are images (screenshots) that are updated every 1 s. I can’t provide details how this screenshots are stored.
i cannot help with the ‘secrecy’ condition.
this is against my philosophy about an open comunity.
will let somebody else to pick up this request.
Going back to the original post:
You can read the Java source of the WebUI.verifyMatch keyword at the following URL
The source code tells that there is no designed limit of the size of input string.
If you try to put a super long string that exceed the memory size of the JVM Heap you allocated (e.g, 2048 mega bytes as specified as default in katalon.ini), you will encounter “OutOfMemoryException”. It is the the actual limit. But @yakovlieva.olena didn’t write that he/she encountered the “OutOfMemoryException”. So I suppose the length of the string is not the real issue.
I guess that the string @yakovlieva.olena put into the keyword was not equal to what @yakovlieva.olena expected. As simple as that. I believe that the keywords are working just properly as designed.
But how, why the code does not work as expected?
---- Only you @yakovlieva.olena can find it. Nobody else can, as you haven’t disclosed enough information.
@kazurayam Thank you for your clarification!
I recognized that there are 2 problems
I run the test within a suit and was able to review the reason of the problem in a TestOps logs.
(in the studio there is no detailed logs for such a long strings). One of two values was defiled as null. I added delay before step that get the attribute = url. No problem now.
If WebUI.verifyMatch() / WebUI.verifyNotMatch() are configured to be failed, test case fails without detailed info. Within test suite test is not finished, infinite loading in job progress. No possibility to check TestOps logs.
You passed a null to WebUI.verifyMatch() keyword. It was your fault that you passed null. The null caused the keyword crazy. The keyword is not defensive enough for the parameter being null.
I think you should not blame Katalon Studio too much. You should write your code more defensive. The simplest way to make sure a variable is not null is:
assert var1 != null
WebUI.verifyMatch(var1, ....)
This is good enough. You should be carefull that you are not passing null to the class/methods of which internal you do not know.
It is a design fault of Java/Groovy language that the language allows you to carelessly pass null as parameter to method calls. Java/Groovy language is not designed with null-safty in mind. In Katalon Studio, we use Groovy. So you are responsible for taking care of null-safety.
Kotlin language is better with null-safety. Kotlin distinguishes nullable variable and non nullable variable at the language syntax level. See https://www.baeldung.com/kotlin/null-safety
@kazurayam Thank you for your comment!
I do not blame Katalon Studio. Excuse me if my problem explanation is sounds like an accusation.
I need to understand how my tests work.
I have added assertions assert var1 != null.
There are no null values.
The is test finished in about 12 min after the last step is failed.
verifyMatch() took 161.321seconds?
Are you happy with this speed?
Crazy slow, isn’t it.
If you want your test run faster, simply you should stop using verifyMatch() keyword to process your ‘strteaming1’ and ‘strteaming2’.
Please do not ask me for alternative. Only you know the nature of the data.
@kazurayam Ok, I will not ask you about an alternative.
I’ll add the better solution finding to my todo list.
Thank you very much for your help!
No is not.
Unexperienced users should use plain java or whatever strong-typing language or stay away from programming.
Groovy is good as it is.
