Brandon Hein
Katalon Ambassador
11/07/2018

Allow for timeout of 0 seconds for WebUI.verifyElement_____ calls.

The user should have the option to validate that an element exists/is visible/etc in the DOM immediately. This is currently not possible with the standard WebUI.verifyElement____ methods, as providing a timeout of '0' seems to default back to the 30 second timeout, and often the next best option (waiting 1 second) is not viable.

Take for example the following scenario, which should demonstrate that waiting 1 second is not a good alternative:

We would like to test a form that contains many, many fields. I write an algorithm (Custom Keyword) that goes something like: "given a set of values provided by the user, if the field is currently present, set the field to the given value". Now lets say that the user provides me with 300 values they would like to set, but only 150 fields exist on the page. Using the current WebUI.verifyElementPresent(myFieldObject, 1) implementation, we now have to wait an extra 150 seconds (1 second timeout for each field not in the DOM).

We currently have to fall back to the Selenium standard approach for doing this kind of thing:

String xpath = object.findPropertyValue("xpath");
return DriverFactory.getWebDriver().findElements(By.xpath(xpath)).size() > 0;


The solution is to either implement a separate verifyElementPresent that does not take a timeout argument, or, as I've said, to make an argument of '0' do what it's supposed to do (return immediately).


Thank you in advance!

Upvote
Quote

Comments

  • Mate Mrse
    Katalon Expert
    11/08/2018
    Upvoted.
    Upvote
    Quote
  • Russ Thomas
    Katalon Evangelist
    11/08/2018
    You could write this in JavaScript and just move on, leaving the WebUI approach as is for those that need it working that way (understand that altering an API as you suggest has a potentially huge impact on legacy code).

    I could get behind something like verifyElementPresentNow(...) though.

    Either way, try the JavaScript approach, by it's very nature, it runs in the execution context of the page -- which is precisely what you're seeking and any webdriver approach (including selenium direct) will never provide.
    Upvote
    Quote
  • Brandon Hein
    Katalon Ambassador
    11/08/2018
    edited November 8
    I could get behind something like verifyElementPresentNow(...) though.
    This, or, as I've suggested, just provide a verifyElementPresent method without a timeout argument (same method name, just a different signature).

    Also, while I agree that changing the behavior of the existing API in regards to how a timeout of '0' is handled would impact existing code, the current implementation is quite poor. As a user, if I pass in a zero, I think it is pretty reasonable to expect exactly that: a zero second timeout. Defaulting back to 30 seconds is both functionally and semantically confusing for everyone.
    Upvote
    Quote
  • Brandon Hein
    Katalon Ambassador
    11/08/2018

    Either way, try the JavaScript approach, by it's very nature, it runs in the execution context of the page -- which is precisely what you're seeking and any webdriver approach (including selenium direct) will never provide.
    I may be misunderstanding your "any webdriver approach ... will never provide" bit, but this is not true. In fact, the workaround that I presented in my original post IS the standard approach suggested by Selenium:

    https://seleniumhq.github.io/selenium/docs/api/java/org/openqa/selenium/WebDriver.html#findElement-org.openqa.selenium.By-

    I'm specifically referencing the "use findElements(By) and assert zero length response..." part of the method description.
    Upvote
    Quote
  • Russ Thomas
    Katalon Evangelist
    11/08/2018
    Brandon,

    Let's take this step by step... this is your first sentence of your first paragraph, wherein, you state your requirement:
    The user should have the option to validate that an element exists/is visible/etc in the DOM immediately.
     The problem I'm solving is the problem as stated -- i.e., execute code, against a page, immediately.

    Then you go on to say (paraphrased), "bunch of code using webdriver". Problem: there is no (or very little) meaning to "immediate" in the context of "webdriver", because, they're executing in different execution contexts.  The only thing webdriver can do, facilitated by you and your test code, is "coopertate" as to timing.  You make a judgement call as to the "when" (while being forced to use at least 1 second). And I'm saying, "meh, I'll do it myself and move on".

    JavaScript, executed by your test code (in Katalon), is injected into the page and executed in the exact same context as the page (in an anonymous function). That means, when it is executed, nothing else on the page is running (since JavaScript is not multithreaded (yet)). I'm saying, it's as close to "now" as you're likely to get.

    And that sir, is true. (Assuming we're ignoring other wayward tech like activeX and all that crapola.) And if you or anyone knows better, please enlighten me!

    Now, we could argue that the call from groovy to kick off the Javascript is still a form of cooperation between the two, and I'd agree, it is. However, I'd say that this use of "immediate" has more meaning. The only "wait" is the time it takes to inject and make the call.  And if you injected up front, even that could be minimized.

    Fair? Or did I misunderstand your requirement?

    Upvote
    Quote
  • Russ Thomas
    Katalon Evangelist
    11/08/2018
    edited November 8
    Also, while I agree that changing the behavior of the existing API in regards to how a timeout of '0' is handled would impact existing code, the current implementation is quite poor.

    Agreed, 100%. There are quite a few oddities in the WebUI API set (I've harped on about them in the suggestions box, too).

    Upvote
    Quote
  • Brandon Hein
    Katalon Ambassador
    11/08/2018

    Brandon,

    Let's take this step by step... this is your first sentence of your first paragraph, wherein, you state your requirement:
    The user should have the option to validate that an element exists/is visible/etc in the DOM immediately.
     The problem I'm solving is the problem as stated -- i.e., execute code, against a page, immediately.

    Then you go on to say (paraphrased), "bunch of code using webdriver". Problem: there is no (or very little) meaning to "immediate" in the context of "webdriver", because, they're executing in different execution contexts.  The only thing webdriver can do, facilitated by you and your test code, is "coopertate" as to timing.  You make a judgement call as to the "when" (while being forced to use at least 1 second). And I'm saying, "meh, I'll do it myself and move on".

    JavaScript, executed by your test code (in Katalon), is injected into the page and executed in the exact same context as the page (in an anonymous function). That means, when it is executed, nothing else on the page is running (since JavaScript is not multithreaded (yet)). I'm saying, it's as close to "now" as you're likely to get.

    And that sir, is true. (Assuming we're ignoring other wayward tech like activeX and all that crapola.) And if you or anyone knows better, please enlighten me!

    Now, we could argue that the call from groovy to kick off the Javascript is still a form of cooperation between the two, and I'd agree, it is. However, I'd say that this use of "immediate" has more meaning. The only "wait" is the time it takes to inject and make the call.  And if you injected up front, even that could be minimized.

    Fair? Or did I misunderstand your requirement?

    Sure, when you try to define immediately, you can philisophically take it as far as you want... all the way down to network latency or processing speed. That's not the point. The entire point of this post was to highlight that the verifyElement_____ family of methods should allow for a zero timeout argument, and, should not, as you've stated (paraphrased) "force you to wait at least 1 second".

    The Selenium approach that I've provided works fine, just as I'm sure that your JavaScript approach works fine. I'm simply suggesting that if the user is going to be offered an out-of-the-box method that verifies the presence/visibility of an element, there shouldn't be a "minimum required timeout", much less an undocumented conversion from zero seconds back to a default of 30 seconds.
    Upvote
    Quote
  • Brandon Hein
    Katalon Ambassador
    11/08/2018
    You're sitting at the bar and call up your friend Bobby Babaganoush.
    You say "Hey Bobby! Come meet me at the bar!"
    Bobby says "Sure my man, when?"
    You say "IMMEDIATELY."
    Bobby says "You got it, I'll be there in a jiffy!"
    Now Bobby has several ways to get to the bar to meet you, all of which will take SOME time (we don't expect Mr. Babaganoush to have teleportation powers):
    1. He can take the bus, which will take him 20 minutes (Selenium approach).
    2. He can drive, which will take him 10 minutes (JavaScript approach).
    3. He can walk, which will take him an hour or more (various other approaches).
    4. Instead of leaving his house right away upon hearing you say "IMMEDIATELY", Bobby boy can hang out and watch an episode Days of Our Lives for about 30 minutes (current Katalon WebUI approach).
    Bobby chooses option #4.
    You are understandably upset with Bobby upon his arrival.
    Upvote
    Quote
  • Russ Thomas
    Katalon Evangelist
    11/08/2018
    It's fine, Brandon, we're in basic agreement over the issue at hand. Perhaps the team will view this and realize they need to take a little more care with method names (I wish) and ensure they can deliver both what they state and what they imply.

    Me? I'll take the pragmatic approach AND post the bug/suggestion. I'm sure you're doing the same with your Se approach.

    Oh, and tell Bobby he missed happy hour.
    Upvote
    Quote
Sign In or Register to comment.