At What Frequency Does WaitProperty Checks For Property

[luisanillo]

I'm currently doing performance tests on a desktop application and I realised that times are not the same when I do the test manually versus when I use TestComplete.

Let's say I'm looking at the time it takes to send results to server after clicking a button. What I do in my code is once the button to trigger the operation is clicked, wait for the result window to appear in order to stop the stopwatch.

I'm getting higher execution time with Test Complete than manually testing (I record the screen, capture the time where I click the button and the time where the window appears to be as precise as possible). Note that the difference of time is significant; around 30 to 40% depending on the amount of data transfered.

var ResultsDialog = Aliases.Sys.TxpApplication.TCCHPDFCreatedList;
ResultsDialog.WaitProperty("Exists", true, 100000);
  
if (!ResultsDialog.Exists) 
{
  Log.Error("Results dialog is not visible after timeout");
}
 
ResultsDialog.ButtonPanel.ButtonCancel.Click();

My question is how often does Test Complete tries to check the "exists" property ?  I have a feeling that it does it at a high frequency, which results in the environnement being overcharged and thus performing it's current operation slowly.

I read the documentation, with no succes, I couldn't not find a parameter to set a frequency.

I know I could use a loop and add manual delay to it, but I would like to avoid that.

Thanks!

[tristaanogre]

I'm not sure any of us schmo users will be able to answer that question.  There is no "frequency" setting but you have to assume that it is often enough and rapid enough to return a result quickly.

As for "Exists"... I would not use WaitProperty for Exists.   Think about it... how do you call the WaitProperty method on an object that does not exist and, therefore, does not have a WaitProperty method?

Waiting for existance is better done with a WaitChild, WaitAliasChild, or other similar "Wait" method that actually waits for the object.  You can also use Find, FindEx, FindChild, and FindChildEx.

[luisanillo]

The object was mapped before hand, so I'm assuming that it knows of it. By waiting for exists, I know that once it's property is set to true, it will be visible.

You may ask why not check for visible, and it is because it fails, since the object does not exists and thus, does not contain a proprerty visible yet.

For you answer about the frequency, I assumed it was quick, but that is the problem. This operation takes around 1 to 2 hours. Imagine querying that property, let's say, 3 times per second. That will surely slow down the whole system, and thus, explain why my results are over what I obtain in manual testing.

Edit: about WaitChild and others, will it do the same as WaitProperty but for an object ? By reading the documentation, I have a feeling that yes it does, therefore, my question still applies; at what frequency and how do I change it ?

Thanks for showing interest in my question!

[tristaanogre]

Mapped <> Exists.  Existance has to do with whether or not the object exists in your machine's memory.  That's what WaitChild and WaitAliasChild do.  

This is the better way of checking existance

var myParentObject = Aliases.MyApp.MyParent

if ((myParentObject.WaitAliasChild('MyChildObject', 1000).Exists) {
    Log.Message("My object exists within 1 second")
} 
Else {
    Log.Message("My object was not present in memory after 1 second")
}

Using WaitProperty means you're putting TestComplete through the cycle of trying to find first of all find the object whose property you're checking before it can call the WaitProperty method.  

[tristaanogre]

As for frequency... I don't know... I'm just a user... but I do know that there's no way in code or settings to change it.  Sorry.

[luisanillo]

What you're saying makes sense, but thing is my code is still working. It does actually wait until my window exists and once it exists, it goes through the code (or of course, until it times out).

I guess I could do as below, and check if the performance is different, but I highly doubt it will change something, since it seems to be doing the same work behind the scenes (I might be completely wrong)

var ResultsDialog = Aliases.Sys.TxpApplication;
ResultsDialog.WaitAliasChild("TCCHPDFCreatedList", DefaultTimeout);
  
if (!ResultsDialog.TCCHPDFCreatedList.Exists) 
{
  Log.Error("Results dialog is not visible after timeout");
}

// Continue

[tristaanogre]

Your code is incorrect.  WaitAliasChild returns the object if it exists... if it does not, it returns a stub.  Change your code to the following.

var ResultsDialog = Aliases.Sys.TxpApplication;
  
if (!ResultsDialog.WaitAliasChild("TCCHPDFCreatedList", DefaultTimeout).Exists) 
{
  Log.Error("Results dialog is not visible after timeout");
}

// Continue

As for how this is different.  There is no search on the mapped tree for the object before you call WaitProperty.  That adds, I believe, an extra burden on the system where as the WaitAliasChild

[AlexKaras]

Hi,

> performance tests on a desktop application

Actually, performance should be measured using the tools like profilers. For example, you may consider AQTime (https://smartbear.com/product/aqtime-pro/overview/).

[TanyaYatskovska · Accepted solution]

Hi @luisanillo,

Also, I would recommend that you read the Monitoring Tested Application Performance article. I think it should help you better understand what is happening on the computer during the test run.