In the previous post, you saw how the Manual Testing has been made really easy with Camano. As I had mentioned, when you run through a manual test case for the first time, the Microsoft Test Runner (MTR) captures your UI actions as an “action log”. You have seen how this allows the tester to “fast forward” through her testing in subsequent runs, where MTR simply plays back the “action log”. This “action log” is also useful when it is time to turn a manual test into an automated test, which, for example, can be used as part of a build verification suite.

Let’s consider the case where you are testing the Windows Calculator and have a test case that checks some basic functionality of the application. You now want to automate the test, add validations, and run this regularly as part of a build cycle. Your goal is to ensure that there are no regressions in this part of the application. This is where the “Coded UI Test” feature of the VSTS 2010’s Test Edition comes into play.

Coded UI Test allows you to generate an automated test from a published test case in Team Foundation Server. You just point to the test case on a Team Foundation Server and code will be generated for the test. Magic!!! Not really. Visual Studio simply takes the action log  stored for the manual test and converts it into code. (Coded UI Test is a new test type in Visual Studio). I really like this simplicity in converting any manual test into an automated test!

As an example, the “action log” for the manual test case noted above may look like:


When you convert this into a Coded UI Test, the actions noted above are translated into the following snippet of code.


Now, in the manual testing case, the tester of course was able to verify in person that the above test case generates the result 9. Coded UI Tests allow to simply add such validations directly into the code. This is as simple as right-clicking the position in the code where you want to add the validation, bringing up the “UI Control Locator”, selecting the control and it’s property in the application that you want to add validation for, and letting the tool add the assertion. Here are some screen shots for the “UI Control Locator”, and the screen to select the control property to validate.



You drag the crosshair of the control locator onto the result box of the application. Click on Add Control and Show Properties. Select the “DisplayText” property and hit OK. The following code gets generated for you.


Presto! You have successfully created a Coded UI Test and you can now run it.

By the way, while in this case  we have generated the automation code from an existing manual test, you can also start from scratch and use a action recorder to record the actions you want translate into code. Here’s a screen shot of the action recorder


Of course, you may not want to use any of the tools, but want to create Coded UI Test right at the API level.  For this, you can use the new Microsoft.VisualStudio.TestTools.UITesting API set to directly reference UI controls, perform actions, and validate properties.

It is also important to point out that code can be generated into any of the .Net languages. In the first version we will support code generation into C# and VB.Net. We hope this further helps break down the walls between developers and testers, where the automation engineers or developers can use the standard .Net languages for test automation code generation and there is no new scripting language to learn.

You will also be happy to know that, continuing with our theme of full integration of features across the life cycle, Coded UI Tests are fully integrated with Team Foundation Server (if you are using one).

  • You can publish the results of a Coded UI test run to Team Foundation Server. A bug may be created in Team Foundation Server from the results of a Coded UI Test run.
  • You can attach the Coded UI Test to a Test Case (see screenshot below). You can then run this automated test from Camano.
  • You can create a data driven test case sourcing its data from a test case on Team Foundation Server.


This then completes a quick overview of the “Coded UI Test” feature. To reiterate again, you will use this feature when:

  • You want to add validations to your test
  • You want to create an automated test and run it as part of the build cycle
  • You want to customize your automated tests to improve its resilience

I am also including a link here for a step-by-step tutorial that walks you through the creation of a Coded UI Test - Tutorial on creating a Coded UI Test

Most of you are familiar with test automation and use it in some form or other in your projects. What you think of this new feature? Are there specific details you’d like me to elaborate in future posts? I am very interested in hearing from you – do leave a comment.