Author: Pramod

Posted On Oct 20, 2011   |   3 Mins Read

Coded UI Test (CUIT) is a new feature introduced by Microsoft for UI Automation. The automated tests created by CUIT are used for the functionality testing of an application.

To know about this tool, we started exploring its ‘Record and Playback’ feature. A very simple test case that we initiated this effort with had the following steps:

  1. Launch Internet Explorer
  2. Navigate to
  3. Search for “Code UI Test”
  4. Validate if the result returned “How to: Create a Coded UI Test” link (an MSDN article on the topic)

Though it generated huge code for such a simple test case, the overall Record and Playback process highlighted the strengths of this tool. The well structured code and powerful element identification mechanism really caught our attention.

Besides that, the CUIT playback engine is also powerful. Playback engine performs duties such as searching for a control and ensuring that the control is visible and ready to be acted upon. Once the control is ready the engine performs actions such as ‘Click’, ‘Select’, ‘Set a Value’, etc. on it.

Recording feature alone is of course, not sufficient for building a full-fledged automation suite. However, CUIT’s recording feature certainly helps you if you decide to write your own scripts. It primarily helps in getting proper hierarchy of controls on the page (such as browser – iframe – div – control) and a set of properties that can be used to identify a particular control uniquely.

We also developed a UI Automation Framework using CUIT. While developing this framework, we experienced that CUIT has got several strengths. Its Recording feature really helped us save development time to a good extent.

Overall, if you decide to go with CUIT, here are some pros and cons of using it for your product:


  1. The element identification mechanism is powerful
  2. Uses C#, the compiled language, which comes with its own advantages over the scripting languages
  3. Works well with Web as well as Desktop applications
  4. Strong support for Synchronization. The Playback Engine allows settings such as “WaitForReadyLevel”, which can be either “UIThreadOnly” or “AllThreads”. It makes the Test Execution stop until either UI Threads or All threads are ready.

Other supported settings are– “Stop on Error”, “Match exact hierarchy”, “Search in minimized window”, etc.

  1. It supports AJAX
  2. The tests can be run on Remote Machines with the help of Tests Agents


  1. Generates huge code for even a small UI operation, and hence hampers maintainability to some extent
  2. Code Reusability is limited; it regenerates code even if it was already generated for a particular action
  3. It uses almost all the Property – Value pairs to identify and locate the UI Controls which at times seems to affect the performance of the script

Guidelines for Automation using Code UI Test

  1. Test creation is certainly a time consuming task, but it is worth going for it if the application under test is pretty stable and has got a large number of tests to be executed repetitively
  2. Having said the above, it is not worth putting efforts in generating Test Scripts for an application which has frequently changing functionality
  3. It can be used for Web as well as Windows applications. It supports,
    1. AJAX
    2. Silverlight

With such advantages and the reliability of the scripts, CUIT appears to be a promising tool for the UI Automation. There are other areas to explore. For example, we have not yet tried it with application containing Flash controls. That might be a topic for a future blog post, but in meanwhile, have you tried it with Flash? Write to us in comments and share your views.