Microsoft® Visual Studio® Team System 2010 introduces a new Test Template named "Coded UI Test".  It enables users to verify the functionality of their user interfaces. 


Coded UI Test is fully integrated into Visual Studio and the new Test Management features in Team Foundation Server. it supports the following tools.

  • Coded UI Test Builder allows users to record test actions and generate code for them. Generated code is re-factored into methods based on user gestures.


  • It also allows users to add UI controls to a UI Control Map and generate assertion code on their properties.


  • Coded UI Test has excellent integration with Team Foundation Server.
    • Users may generate code based on an action recording created in Microsoft Codename Camano and published to the Team Foundation Server.


    • The Results of a test run may be published to Team Foundation Server. A bug may be created in Team Foundation Server from the results of a Coded UI Test run.
    • The Coded UI Test many be attached to a Test Case in Team Foundation Server.


    • Coded UI Tests may be run as part of a Team Build run.
    • Coded UI Test can be generated from Shared Steps created in Camano.
    • Coded UI Test can be data driven with data associated with a Test Case on Team Foundation Server.
  • Microsoft.VisualStudio.TestTools.UITesting API may be used to directly reference UI controls, perform actions and validate properties.

The underlying Action Recording Engine for Coded UI Test is shared with Microsoft Codename Camano.

The following sub-sections provide details on the features supported by the engine.

· Intent-aware, non-intrusive and resilient action recording: Instead of just capturing raw user actions, the engine has been designed to be intent aware. Set of actions are aggregated into equivalent action to provide an intent aware playback.


Additionally, the engine uses smart algorithms to accommodate changes in configurations like window resize/Minimize/Maximize, screen resolution changes etc to provide a resilient playback support.

· Strong UI technology and platform support: The engine supports a wide range of platforms out-of-the box covering thick client applications built with .Net technologies to latest web applications

  • Windows Internet Explorer 7.0 and Windows Internet Explorer 8.0
    • Support for applications written in ASP.Net, php, jsp, asp, Ajax, SharePoint and web 2.0 applications.
  • Win-forms Controls for Microsoft .Net framework 2.0, 3.5 SP1 and 4.0
  • Windows Presentation Framework (WPF) for .Net framework 3.5 SP1 and 4.0

Internally the engine uses features of IEDOM for recording actions on the web applications being tested via Internet explorer. It uses accessibility technologies in Windows to capture actions on AUTs. Specifically it uses Microsoft Active Accessibility (MSAA) for Win-form support and UI automation (UIA) for WPF support. Custom controls that are developed for Win-form and WPF that follow accessibility guideline are also supported.

· In-built sophisticated mechanisms for handling complex UI action recording scenarios

  • Fast Search: In order to be able to playback user actions, the engine must be able to search for the Control that was acted upon. It uses fast search algorithms to quickly identify the controls and take appropriate actions on them.
  • Wait For Ready Mechanism: When playing back an action the engine needs to know that the UI is ready to act on the next action. For example, if the application was navigating to a web page, the engine needs to wait for the navigation to complete before taking an action. The Wait For Ready mechanism provides this support by intelligently detecting the application’s readiness to act on the next action.
  • UI Synchronization: If the user acted on a control (e.g. a mouse click), the engine needs to ensure that the control actually did receive the input. UI synchronization feature provides this support to the engine allowing it to perform a more resilient playback.
  • Ensuring UI is Visible: In a fast-forward scenario, the UI element (e.g. a list box) that needs to be acted upon might not be visible (scrolled our) or hidden behind another window. This feature ensures that the element is visible before taking an action on it.

Extensibility Support: The engine has been designed with Extensibility in mind. We realize that there are scenarios where our default engine will not meet the needs of our customers. These include being able to test applications built on a different or new UI technology (e.g. flash) or certain application domains that require customized action recording support. Via our extensibility APIs