Better/Automatic delays on actions

During all my testing, the most recurring problem i’ve encountered is the fact that Katalon goes through the script way too fast and elements don’t have the time to load properly. Then you get a “not found” error and you have to go back and :

  • Use a “wait for…” command, which is nice but does’t always work either (making test results not very reliable, since sometimes a script will validate, sometimes it will false-fail)
  • Use a “Delay” command, which has so far been the best solution but it’s annoying to drop “Delay” every 3 lines of script
  • Use a project-wide global Delay, which also works but makes the script super slow since you can’t set it to lower than 1 second

It would be nice to have Katalon be more intelligent in the way it executes actions, especially “click” or “send text” ones. I was wondering why does the “wait for element clickable” for example even exist, why isn’t it always included in a “click” or any other command that directly interacts with an object? Maybe keep the “wait for” commands for cases where you really NEED to verify the state of an object, but otherwise include them all in the appropriate interaction commands?

Also, it might be very useful to be able to automatically retry a step/action during execution. I know it can be done with code but considering how often things take a while to load on a website because of bad connection, low-power dev/testing servers, browser issues etc, it’ll be too much a hassle to individually “retry” all your actions.

2 Likes

Both the webdriver code and the browser code are trying to execute at full machine-capable speeds. The browser is suffering from the network latency you described but the webdriver code (Katalon) is not. Therein lies the problem.

As the test coder, you need to devise ways to slow things down in the test code. You make good, valid points as to why that’s tricky. I don’t believe there are any good inbuilt “wait” APIs/commands that are 100% reliable for the purposes we are intending to use them. All of them are trying to interpret state without being able to ask the AUT directly “are you ready?”

The only cure I’ve found is to ask the page directly, in JavaScript. Doing that, I get a definitive answer, not a third party’s interpretation which is not much better than “maybe, try it and see”.

To say that another way, I’m asking a better question and asking the page itself, not asking a third party (webdriver/Katalon) or being forced to ask a preformed question supplied by the third party. Ask yourself, who knows best? The page or the third party?

Sometimes I still need to go back and tinker with the fine details of the question (i.e. ask a better question) but it is far less prone to error and misjudgement and works 100% of the time. And when I alter/add to the question, I end up with a better question, giving me a better answer, not yet another version of “maybe, try it and see”.

Finally, understand this key detail: when you execute a call to JavaScript from your groovy code, it is executed in the context of the page. This is because in the browser, JavaScript is executed in a single thread (for the most part, but we’ll ignore the rare cases where this is not quite true) which means it is synchronous with respect to all other code running on the page. Groovy (i.e. webdriver/Katalon) code cannot even hope to achieve that.

Caveat: Injecting JavaScript into the page is altering the page itself. From a purely scientific and procedural standpoint, that is not good. So it’s a trade-off. Want to get work done? Then do what you gotta do B)

I was wondering why does the “wait for element clickable” for example even exist, why isn’t it always included in a “click”

Because it’s inherently unreliable and there is no fix for the problem due to the nature of the problems you and I both described. If it were to be auto-included everywhere, you’d be exporting/importing the problem everywhere else. No thanks!

Also, it might be very useful to be able to automatically retry a step/action during execution.

Now that, on the other hand, is a reasonably good idea. I’d certainly upvote it as a single proposal.

Russ

3 Likes