This project is read-only.

CUITe takes more time for script execution when compared to UIMap execution?

Apr 16, 2012 at 9:31 AM


I recently started using CUITe for my windows app test automation and when i compared my test scripts in CUITe with the UIMaps, CUITe performance seems to be very slow. I mistakenly raised a question on msdn forum with the source code and the changes that i did to CUITe_WinWindow after which the performance seems to be ok but not desirable. The complete explaination is available @ Can anyone please guide on how to acheive a better performance with  CUITe?



Apr 16, 2012 at 10:50 AM

WinControls is not yet covered by CUITe. This is still under development (I am busy with so many things at work).

Did you add support for WinControls yourself? If yes can you share all the code? I can check why it is slow.


Apr 16, 2012 at 11:24 AM

Do u want me to share it on skydrive. If Yes, can u pls provide me ur mail id?

Apr 16, 2012 at 11:40 AM

please submit the .zip file (without binaries) as a patch at

Apr 16, 2012 at 12:28 PM

I have uploaded a patch though i am not facing that performance issues now. Actually i found that patch for WinControls support is already added. To extend that, i have added overloaded Get method to take in parameter specifying the search parameter for the parent control. There is one more overloaded version of Get method with UITestControl as a parameter that acts as a search container for the child objects. But i forgot to mention these overloaded Get methods in the description while uploading.



Apr 16, 2012 at 12:49 PM

One more thing. I forgot to clean the solution, so binaries might be present. Sorry for that.

Apr 17, 2012 at 5:11 PM

Hi Pratap,

Last week I uploaded the first patch to provide support for WinControls. I am continuing to work on it and have been asked by sureba to do some testing and create a sample test project. I was just about to upload an update when I saw your patch that contained my in-progress sample...strange how code makes it around so quickly! I will say that I am a little taken back by your willingness to upload someone else's work...

Like sureba said, this feature is under development, so please refrain from submitting changes to unreleased patches. If you have any feedback or find any problems, please use the forum to discuss. 

I had already made the change to the Get<> method for specifying a different container object than the top-level window. I also added wrappers for most if not all of the WinControl properties.

The patch will also include the same level of functionality for WPFControls. Since it was so similar to WinControls, I decided to get started on that too.


Apr 18, 2012 at 4:55 AM

Hi Matt,

Sorry for creating all the mess. Ok, below is the complete story.

I got CUIte solution from one of my colleague (Daniel)  and it was already having all the WinContrlols support and so i came to an assumption that it is a released version and i can use it the way i want. So since i was thinking that it is a released version of CUITe i raised a question on msdn,, asking for help on how to improve the performace. Then later on i have added two more version of Get method to the framework and again replied back to the same post on MSDN ( you can refer the msdn link). Then i got a reply from MSDN that i raised a question on a wrong forum and was asked to raise on cuite.codeplex discussion forum. So i came to cuite.codeplex and started a discussion (you can read the first conversation of this post). Then Sureba replied back saying CUITe does not contain any WinControls support yet and i was surprised but i was in a hurry to get the performance better of CUITe.  Since Sureba was asking for the solution i just uploaded a patch @ with little care of providing a full fledge description. Then when i clicked submit, it listed out all the patch that were submitted for CUITe and below my patch it was your patch. Then i thought Oh my god, is this not released yet? So i replied back here to Sureba (again you can read my 3rd conversation with Sureba). I was all confused who actually added a WinControls support and that is why in my 3rd conversation i said "i found the patch" (i did not said i have added the WinControls support and i have never said i have added anything to the framework except those two Get versions). I just wanted Sureba to get the source code so that he can debug and let me know why that is so slow.


Sorry Matt for all the confusion, but in no way i had any intentions of taking any credit for the work that you have done. Please reply back if this clear.

Apr 18, 2012 at 3:32 PM

Hi Pratap,

No worries. I accept your explanation of the situation. 

Regarding the problem with slowness, I have noticed the following issue with Coded UI. If you have two solutions open and you are using one of them to record or identify objects, this can cause the execution of the other solution to be slow. The issue seems intermittent, but the way I work around it is to close the solution where I was using the Coded UI recorder and possibly restart the other solution.

Overall, I have seen CUITe performance be about the same as pure Coded UI, perhaps about 5-10% slower. By using the CUITe wrapper, you are gaining ease of test development, so to me this greatly outweighs the a small performance hit. Since CUITe is a wrapper, it is understandable that it would add some amount of execution time. Also worth noting...CUTIe methods like Click() have a call to UITestControl.WaitForControlReady(). Recorded Coded UI tests don't included these calls, which can add a small amount of time to the process.


Apr 19, 2012 at 7:20 AM

+1 to Matt.

Almost all wrapper methods in CUITe has a call to WaitForControlReady(). This is added with purpose. I have found tests written using CUITe are more consistent mainly due to this inclusion of WaitForControlReady(). Hope that clarifies.


Apr 25, 2012 at 10:23 PM

Thank you, Matt!

Your patch has been applied in changeset #16149.

I had to fix a few things for backward compatibility, but not much.

Apr 26, 2012 at 3:38 AM

In regards to performance, here are some links that explain the essential playback settings that you can configure in your coded ui tests that affect performance:

Hope that helps!