Smart Wait and xpath Feature of Katalon 7

Product Forums Katalon Studio
,
1

Hi

We are currently using Katalon 6.3.3.11 and evaluating Katalon 7. Katalon has mentioned one important feature “Smart Wait” and i would like to get answers to my below questions so that i can run my existing test script in V7 which is developed in V6 and see the difference as how “Smart Wait” is making difference. We have given delay at different steps as application behavior is not consistent on page load. Also, when there is more load on system then there are more failures because of delay issue

Is “Smart Wait” Feature available in Free edition of katalon 7?

Currently we have given static delay and dynamic delay (Wait for element clickable, Wait for element visible, verify element present etc). Do we need to remove these delay if we enable “Smart Wait” at Project Level?

Do we also need to remove other delay given at Project Level and just enable “Smart Wait”

How Katalon is handling xpath in 7 as we have seen because of DOM structure change xpath gets changed and automated scripts fails. Other tools (like Provar and TOSCA) use Salesforce meta data to identify element/object and in that case there is no failures.Our automation is mainly for Salesforce

Please answer these questions and also provide guidance to judge difference between 6 and 7 in context of “Smart Wait” and xpath

Thanks with Regards
Deelip

2

Yes.

You need to take a pragmatic approach. Test your Tests to find out. I have smart wait enabled. I changed nothing in my code base.

There is no significant change in the handling of locators. In Xpath’s case, there is something called Auto-healing Smart XPath.

The documentation available already covers that. Where it fails you, post a new topic here - someone will be able to help.

1 Like
3

Smart Wait is not an alternative to Wait Keywords - they have their uses. Smart Wait is intended to alleviate the timing problem for users by reducing the amount of wait code you need to write.

It is worth emphasizing reducing, and not replacing. Therefore if you are trying to take advantage of the feature, you need to find out to which extend Smart Wait helps with your tests. Make a copy, remove all waits, run it multiple times, and add Wait keywords where they are still needed.

7 has Smart Wait, 6 doesn’t. Both 6 and 7 has Smart XPath. 7 is the officially supported version, while 6 is no longer maintained.

4

Thanks Thanh and Russ for your response but sorry to mention i am still not clear what “Smart Wait” will do if we still need to give wait for each action

My understanding was, we do not need to give any additional delay between different action and Smart wait will handle it if it is enable at project level, meaning script will wait till the element is clickable before it actually click it

Currently we have given many delay in scripts as application behavior is not consistent, copying and deleting all those delays and try testing is big exercise

Could you please tell me What Smart will do and Not do so that i can understand its usage benefit

Thanks with regards
Deelip

5

@Deelip_Kumar_Saxena

Most often time when there are activities going on in the website, there will be network requests. Smart Wait attempts to wait for the page to be relatively static, i.e waiting for the network requests to finish.

A vivid (vastly simplified) example would be a submit button on a form that implements some validation logic. When you input the info, the validation occurs through network requests to and from the server, and during this time the button is disabled. If you try to click on it when it’s disabled, your test would fail.

Normally, there are a lot of network requests happening on the page as the test is executed, so Smart Wait would (heuristically) try to wait automatically and resume execution as it deems fit.

It’s not that simple, Smart Wait does help, but it’s not a magic pill.

It helps you write less delay in the future, only write when Smart Wait can’t do it for you.

I’d advise trying to enable Smart Wait and remove some delays first to see if it helps. Unfortunately I still think it won’t fix all your problems, and you’d still need to decide when to use it.

6

@Deelip_Kumar_Saxena

I understand you have spent many hours of frustration trying to evolve a good wait-strategy. And, hence, why you have so many questions about the topic.

I think I can intuit a vision of your code by what you said above. If you need to fill out a set of fields and click three buttons, you are probably waiting a lot of time to be sure everything is “ready” before making each move.

My approach is very different.

My advice is that you change how you structure your test cases. Each test case starts out by waiting for EVERY element that the test will deal with BEFORE you interact with the elements. Something like this…

/*

1. Wait for the page to be loaded.

2. Wait for any XHR requests to complete (jQuery/Angular et al).

3. If there are spinners, wait for them to disappear.

4. Wait for large elements to be visible (tables, grids, etc).

5. Wait for dropdowns to be populated.

6. Wait for text input controls to be visible.

7. Wait for action buttons to be visible (and maybe clickable too).

X. Start the Test Case here...
*/

The order of 4-7 can be changed to suit your purposes. Some of them may not be required on your page(s). Either way, do them before X. Start the test case here…

If your page makes XHR requests during the lifetime of the page, make sure you repeat any steps where the XHR might cause changes to the elements on the page.

Philosophy: Your automation user (i.e. your test case code) is a faithful and speedy but dumb robot. He does exactly what you tell him to do - very quickly. If you structure your test case code as above, he suddenly becomes “less eager” to run across your page and do the task you set him too quickly.

Once you begin to code your test cases this way, you will start to see a pattern emerging. You might ask yourself, “Why can’t I write a generic version of this idea and pass in the bits that change, page by page…?”

Good news - you can. You’re getting real close to writing your own POM (Page Object Model). In Katalon, this is best done using custom keywords.

“But Russ, that sounds like a lot of work!"

Depends how you look at it. What you’re doing right now is to a large extent not working hence all the questions you have about waiting and Smart Wait. It’s obvious to me you’ve spent hours on this. I bet each time you need to add/extend tests you tread with trepidation into the code prepared for yet another round of hit and miss with regard to timing. And let me say this, I bet your tests are still not 100% solid with regard to sync tasks.

To me THAT sounds like a lot of work.

7

Thanks Russ and Thanh for your input!

Let me try executing my test cases after removing delays and see how it is behaving

Thank for your guidance!!

Thanks
Deelip

1 Like