Sometimes TestObject is not found, but visible on error screenshot

Product Forums Katalon Studio
,
1

I have a HTML page with two input-buttons and one big table (pure HTML-text = 339 kByte).

My TestCase is looking for one of these buttons:

boolean isButtonFound = WebUI.verifyElementPresent(myButtonTestObject, 1, FailureHandling.OPTIONAL)

The button is identified via attributes:

Selected Locator = "//input[@name = 'actionBtn' and @value = 'Update' and @type = 'submit']"

If the button is there, the test is supposed to do action A, if the button is missing the test is supposed to do action B. This works in 98% of all test runs.

But sometimes, the button is not found by “verifyElementPresent()”, although it is visible on the screenshot, which is automatically taken when “WebElementNotFoundException” is thrown (button has not been found). Looking at the AUT’s state, the button should be there, too. But since it is not found, the test case chooses action B. Action B does not fit to the AUT’s state and the test run fails.

The button is defined in line 300 of the HTML page with a total of 22.500 lines. Delivery to the testbrowser should happen quite early.

All this is packed in a while loop:

...
while(true) {
    WebUI.waitForPageLoad(10)
    WebUI.delay(3)

    boolean isButtonFound = WebUI.verifyElementPresent(myButtonTestObject, 1, FailureHandling.OPTIONAL)

    if (!(isButtonFound)) {
        break;  // action B
    }

    WebUI.click(myButtonTestObject)   // action A: reload the HTML page
}

I am using Katalon Studio 7.1.2 with Firefox 60.9.0esr.

Do you have any ideas, who to avoid the “button not found, although it is there” problem?

Thanks for reading!

2

“presence” is not the same as “visibility”

What you’re seeing, I believe, is a slight issue over timing - your test code runs super quick, browsers are (comparatively speaking) super slow.

Try waiting for the element(s) to become visible.

Elements that are present are merely present in the DOM.

Elements that are visible are present in the DOM AND visible on screen.

3

@Russ_Thomas: Thank you for your quick reply.

I figured out some new information: It seems that WebUI.waitForPageLoad(10) does not work in my case (I know, I am not the only one with this problem). Watching my firefox and katalon test execution in parallel, I see the following:

  • firefox needs 16 seconds to load the webpage (long database query and big html table)
  • in those 16 seconds, I see katalon executing the loop (mentioned above) 4 times

So WebUI.waitForPageLoad(10) does not pause the test until the page is loaded in firefox. Instead katalon test execution goes on.
I guess, the page is completly loaded at some random time in test execution. In this case, it can easily happen that the button is still there when test execution is at WebUI.verifyElementPresent(myButtonTestObject .... Then the new page (without the button) is completly loaded. And so the following WebUI.click(myButtonTestObject) fails, since the button is gone.

Any ideas how to solve this?

My next plan would be to add a timestamp (milliseconds) in EVERY html page renderd by our AUT. So I could wait until the current page in firefox has a new timestamped, compared to the old page. :wink:

4

That sounds a lot like my AUT.

Does the whole page reload? Or just the table?

5

Did you try WebUI.waitForElementVisible as @Russ_Thomas suggested ?

You can try with 16 as timeOut, or a little more.

6

The whole page does reload. What do you think about my idea with the timestamp in the footer?

I think, this won’t help, since the old page (still visible in my test browser) and the new page (beeing retrieved from the AUT; and katalon should wait for) are quite similar. My current test is a reload of the same page.
WebUI.waitForElementVisible will find the element in the old page and will happily continue with the next test step.

I would like to avoid fix delay times. Since application, database and network performance will vary. So one time it might be 14 seconds, another time it might by 20 seconds.

7

It would work, I think. But it’s also like giving in. :confused:

Does the AUT throw up a spinner/dimmer/hourglass/anything when it’s making this change?

What about the URL? Does that change in any way?

8

Clicking the button triggers a HTTPS POST. The page has no JavaScript. So there is no spinner, hourglass or anything.
The URL does not change either. It is a plain page reload.

I think, I’ll try the timestamp idea… Thanks for your help!

9

Okay. Follow this precisely:

  1. Open the page yourself (manually) in the browser.
  2. Append this to the URL:
    https://your-current-url/some-page.html?peter=1
  3. Now trigger the page reload yourself by clicking the relevant button that causes the reload.

Does peter=1 survive?

I’m expecting a “no” to that. And, if so, we have a solution in the works…

We will be modifying the AUT “live” to suit our testing purposes. This comes with the usual warnings about modifying the AUT. However, when the gatekeeper is being totally unreasonable about letting you in, go round the corner and scale the fence. :wink:

Let me know how peter=1 fairs.