Forum Discussion

jefr's avatar
jefr
New Contributor
9 years ago

TestComplete not waiting for page loads when api call done with different variables

Changes to a textbox on the page we are testing results in 2-4 api calls to the same url but with different variables   /configure/ConfigureServlet?action=getFlatOptionStore&currentOrder=-140&curre...
ajax
API
delays
xhr
  • Colin_McCrae's avatar
    Colin_McCrae
    9 years ago

    I take it these are AJAX type calls triggered within the page logic somewhere? So it's not a full page reload so you can't check the page readystate?

     

    Are there any on-screen cues or indicators you can use? How does the user know these calls are complete? You mention about a textbox being cleared, is that as a result of the calls?

     

    Failing that, do any properties on the page, or the objects on it change, when the calls are made/complete?

     

    In short, you need to find something you can see/lookup/inspect that keeps you in line with these calls ....

AlexKaras's avatar
AlexKaras
Champion Level 3

Hi,

 

Actually, TestComplete waits for the page to load. The case is that the page is not reloaded in your scenario, but some additional data request is executed from the page script code and obtained data injected into the page. This changes page contents but, again, does not reload the page and thus TestComplete has no reason to wait for something. See https://community.smartbear.com/t5/Functional-Web-Testing/How-to-Map-a-JS-Element/m-p/123369#M27864 for maybe some additional explanation of this behavior.

What you have trapped into is the biggest problem of modern web applications testing: you cannot rely on the fact of page load and must find some reliable indications that you can proceed further but not to wait for something to happen.

 

As a side note: considering the fact that TestComplete (and, accordingly, the human end-user) can enter the data in the filed before this field is updated by web page script code and this causes entered data loss, doesn't this mean that there is a problem in the tested web page? Shouldn't it prevent end-user from entering data in the field before this field is processed by script code?

 

Colin_McCrae's avatar
Colin_McCrae
Community Hero
9 years ago

As Alex says, in-page calls like this can make automation difficult.

 

But if you have a helpful dev team, there are some things they can do to help ....

 

http://www.w3.org/TR/navigation-timing/

 

We use these embedded in our web applications for performance testing. (We run swarms of cloud machines with each running a script, gathering these response times, and reporting them back to a central controller. Totals are compiled, graphs produced etc etc ...)

 

However, you can also use the marks left by these (assuming they are wrapped around AJAX events - which is simple to do) to determine when a call has completed.

 

So it's a double win. You can tell when an in-page call completes. And if you decide you want to use real browsers and a cloud swarm for performance work, you have timings for all your in-page requests built in and ready to go!

 

All 3 of the main Windows browsers support this. (FireFox, Chrome & IE. I would assume Edge does as IE already did.)