Mathew Aniyan's Blog

Generate Code for Coded UI Test [Beta2]

2009-11-05T03:09:03Z

When a Coded UI Test is created, a set of files are added to the Project. Code can then be generated and added to the Coded UI Test project

By using an action recording associated with a test case.

When a manual tester runs a test case in Microsoft Test Runner and publishes the results to Team Foundation Server, an action recording is associated with a test case. This action recording is an XML file which describes the controls and actions performed on them. Code will be generated corresponding to actions and controls in the action recording.

2. By using the Coded UI Test Builder

Using the Coded UI Test Builder, you can

a. Record your test steps

b. Add controls to a UI Control Map and then use these controls to perform test actions.

c. Add Assertions on UI Controls

3. By Hand-coding

In this case, tool does not generate any code. UITesting API can be used to locate controls on a user interface, perform actions on them and validate its properties.

These options are available from the Generate Code for Coded UI Test dialog.

They can also be accessed from the context menu in a Coded UI Test method.

These options are also available from the menu under Test.

Tutorial – Coded UI Test [Beta2]

2009-11-05T03:02:44Z

Overview

This tutorial guides you through the creation of a Coded UI Test in Visual Studio 2010.

Steps

1. In Visual Studio 2010, click on Test menu and choose New Test

2. In the Add New Test dialog, choose Coded UI Test and click OK.

NOTE:- You can choose to create a Visual C# test project or a Visual Basic test project.

3. In the New Test Project dialog, change the Test Project name and click Create.

4. In the Generate Code for Coded UI Test dialog, choose Record actions, edit UI Map or add assertions

5. The Coded UI Test Builder will start up.

6. Click on Start Recording button to start the recorder.

Note: There is a slight delay when the recorder starts. Ensure that the button changes to the Pause Recording before recording test steps.

7. Now perform the desired test steps.

For the purposes of this tutorial, we are going to test the Add function in Calculator.

NOTE: Coded UI Test works on Web (IE 7 & 8), WinForms & WPF apps. I am choosing Calculator as an application which anyone who is evaluating has access to.

The Test steps are

a. Launch Calculator

b. Click 7

c. Click the + sign

d. Click 2

e. Click = button

Note that a text description of actions will be shown in the Recorded Actions window.The Recorded Actions window can be pinned if you want to see the actions being recorded. It will become semi-transparent when you move focus away from it.

8. Click on the Generate Code button and change the name of the method to TestAdd.

Click on the Add and Generate button to add this method to the project.

9. Now drag the cross-hair and drop it on result field in the calculator. A blue rectangle is drawn around the selected control.

10. Properties of the selected control are shown in the Coded UI Test Builder Window. Right click on the Display Text field and choose Add Assertion.

11. In the Add assertion for DisplayText dialog, click OK.

12. Click on the Generate Code Button and change the Method Name to AssertSum.

Click on the Add and Generate button to add this method to the project.

16. Close the Coded UI Test Builder by clicking on the X button.

17. The Coded UI Test is now opened within the Visual Studio IDE.

NOTE the following characteristics about the generated code.

a. The CodedUITest1 class is tagged with a Coded UI Test attribute.

b. The CodedUITetMethod1 method is tagged with a Test Method attribute.

c. in the CodedUITestMethod1, the methods we created are invoked.

18. Note the following in the Solution Explorer.

a. All required references for Coded UI Test are added automatically.

b. 5 files are added to the Test Project

i. CodedUITest1.cs - main Coded UI Test class, Test Methods and Assertions.

ii. UIMap.uitest – XML Representation of the UI Map (a container of UI Controls) and the recorded actions.

iii. UIMap.Designer.cs - Code generated for the UIMap

iv. UIMap.cs – empty file where UIMap customizations may be added.

iv. UserControls.cs - Specialized classes representing various UI Controls referenced in the Test.

19. Right-click inside the Coded UI Test Method and choose Run Tests

20. The code is compiled and then the test is run.

21. All actions recorded earlier will now be played back.

22. After the test run is completed, right-click on the Test Run and choose View Test Results Details.

Congratulations. You have successfully created and run a Coded UI Test.

Visual Studio 2010 Beta2 is now available

2009-10-21T03:42:00Z

You can download it here.

See the official announcements.

http://blogs.msdn.com/somasegar/archive/2009/10/19/announcing-visual-studio-2010-and-net-fx-4-beta-2.aspx

http://blogs.msdn.com/jasonz/archive/2009/10/19/announcing-vs2010-net-framework-beta-2.aspx

http://blogs.msdn.com/amit_chatterjee/archive/2009/10/20/visual-studio-2010-beta-2-is-now-available.aspx

NOTE: Beta 2 is also comes with a “go-live” license, which implies that you can deploy the tools for your “live” projects in production (view the license agreements for more details). This is a really a great opportunity for you to get going with this Visual Studio release!

My favorite feature is TFS Basic. I believe this removes the major pain-points in adopting TFS & VSTS 2010 for small teams. I now have it running on my laptop.

The key changes in Coded UI Test are

1. The code generation (from recorded actions, control in UI Control Map, assertions) have been significantly modified. You will notice that code is better organized now. It is automatically parameterized allowing you to data-drive coded ui test easily.

2. The user interface for Coded UI Test Builder has been enhanced significantly based on usability feedback.

3. Support for WPF controls is much richer now.

Configuring Playback in Visual Studio 2010

2009-08-10T15:03:00Z

In a previous post, Abhishek had talked about the Record and Playback Engine in VSTT 2010. The Coded UI Test feature in Visual Studio 2010 also uses this engine to playback UI actions. In this post, i will describe the various settings for Playback and how you can modify them to improve the resilience of your Coded UI Tests. Playback is configured by modifying the fields in Playback.PlaybackSettings class.

1. Continue on Error

When you are recording a Coded UI test on a login page, the “Auto Complete passwords” popup may have appeared.

When you playback actions on the login page, this dialog will *not* come up. So the action that you performed will cause an error. To improve test resilience, the Record & Playback engine automatically marks this action as “Continue on Error”. When the test is being played back and the error occurs, the engine will continue on to the next action. Specific actions (IE popups, implicit Hovers) when performed by the user are tagged by the engine as “Continue on Error”.

In Coded UI Test, you have the flexibility to turn on “Continue on Error” for any action. This is done by the following code snippet.

Playback.PlaybackSettings.ContinueOnError = true;

Remember to turn this flag to false after the section where there are potential failures. Otherwise the engine will ignore all errors and your test will return incorrect results. By default this flag is set to false in Coded UI Test.

2. Match Exact hierarchy

The Record and Playback Engine uses a hierarchical structure to locate controls. The Yes button in the dialog above is identified as

To locate YesButton during playback, the engine will search for AutoCompletePasswordWindow, then for YesWindow in it, and finally YesButton in YesWindow.

Sometimes application may change so that the hierarchy gets modified. Record and Playback engine attempts to locate the control, in such cases, by skipping the intermediate elements in the hierarchy. Thus in the example, if it is unable to locate YesWindow, it will search for YesButton directly under AutoCompletePasswordWindow and all its children. This behavior can be controlled by the “Match Exact Hierarchy” setting. This is done by the following code snippet.

Playback.PlaybackSettings.MatchExactHierarchy = true;

If the flag is set to true, every control is the hierarchy will be searched in order. Any failure will result in failure to locate the control.

By default, this flag is set to false. Note that this may sometimes lead to false positives i.e an unintended control may be identified. In such cases, you will have to change this setting.

3. Search in minimized windows

The Record and Playback Engine searches for controls even inside minimized windows. The minimized window is restored and actions performed on the control inside it.

You have the ability to turn this feature off i.e. prevent the engine from looking at minimized windows. This is done by the following code snippet.

Playback.PlaybackSettings.SearchInMinimizedWindows = false;

4. Smart Match

The Record and Playback Engine identifies controls on the user interface by its search properties. e.g:- The standard calculator window is identified as below.

SearchProperties[WinProperties.Window.ControlType] = ControlType.Window.Name;

SearchProperties[WinProperties.Window.Name] = "Calculator";
SearchProperties[WinProperties.Window.ClassName] = "CalcFrame";

Some of the search properties may change over time. Record and Playback engine uses a Smart Match algorithm to identify controls if they cannot be located using the exact properties. The smart match algorithm uses heuristics and attempts to locate the control using variations on the search properties.

You can control when Smart Match should be applied. By default Smart Match is applied for Top Level Windows and all controls. You can turn off Smart match using the following code snippet.

Playback.PlaybackSettings.SmartMatchOptions = SmartMatchOptions.None;

The default settings (Smart match top level windows and controls) is optimal for a resilient coded UI test. But sometimes it may lead to false positives and then you will have to modify this setting.

5. Wait For Ready Level

The Record and Playback engine ensures that each UI control is ready to be acted upon before performing any action. The smart “Wait For Ready” algorithm significantly improves the resilience of your Coded UI Test. Now you don’t need to add the annoying Sleep statements whenever a UI Control is busy and not ready to receive input. By default, the engine checks the UI Thread (foreground thread) to determine if a control is ready.

You can turn off Wait For Ready completely by the following code snippet.

Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.Disabled;

Alternately you may want to wait for all threads including background threads. This may be required if the application is making asynchronous calls that results in UI changes. You can do this by the following code snippet.

Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.AllThreads;

NOTE that this setting will slow down the engine and should be carefully used.

6. Set Property Verification

After setting the property of any UI control, the record and playback engine performs a verification pass to ensure that the set succeeded and the UI control now has the value assigned to it.

e.g:- You type the text “MSFT” in the search edit box in Bing. After playing back this action, the engine reads the text property of the search edit box to ensure that this set has succeeded.

In certain applications, the set property may trigger off some business logic which then changes that property itself. In such cases, the verification fails. If your application exhibits such a behavior you can turn of the set property verification using the following code snippet.

Playback.PlaybackSettings.SkipSetPropertyVerification = true;

7. Fail Fast

The Record and playback engine’s search algorithm has a fail fast logic. i.e. If the engine is reasonably confident that the search will not succeed, it will return with a failure. This ensures that you are not waiting for a non-existent control for 2 mins (the default search timeout).

Sometimes you may want to disable fail fast. Typically, you do this along with increasing your search timeout. You are confidant that the UI control will become available within a specified duration (which is longer than the search timeout) and you want the engine to wait for that duration. You can do this by using the following code snippet.

Playback.PlaybackSettings.ShouldSearchFailFast = false;

8. Misc

Other playback settings which can be modified include

a. Delay Between Actions: How long should the engine wait before performing two successive actions? By default, 100 ms.

b. Search timeout – How long should the engine attempt to locate a control? By default, 2 mins.

c. Wait for Ready Timeout – How long should the engine continue waiting for a control to be ready? By Default, 60s

d. Think Time multiplier – For slow machines, assign a high multiple so that the recorded think time is scaled up to handle slower application responses.

e. Send Keys As ScanCode - By default, the engine sends keys to the application under test as Unicode. But in certain cases, it may need to send keys as scancode. Sending Unicode to such applications will result in failure

f. Encryption Key Location – When recording password fields, the record and playback engine uses a hard-coded key for encrypting the value. A custom encryption key can be set using the SetEncryptionKeyLocation()

g. IME Languages List – These are the languages for which IME is enabled and IME ends composition on pressing the {ENTER} key.

NOTE: The Test runner tool in VSTT 2010 also uses the Record and Playback Engine. You can configure the playback settings described above in Test runner tool from

a. mtlm.exe.config – located in %VSINSTALLDIR%\Common7\IDE

b. Microsoft Test & Lab Manager, navigate to Lab Center –> Test Settings , open the applicable Test Settings, select Data and Diagnostics section and click on the Configure button next to Action Log and Action Recording. In the Advanced section of the dialog, some of the Playback settings described above may be configured.

The managed reference for PlaybackSettings class is here.

Interesting articles on Automated Testing

2009-06-19T06:09:03Z

Ed has published some interesting articles on automated Testing.

http://blogs.msdn.com/edglas/archive/2008/08/15/so-you-want-to-automate-your-test-cases.aspx

http://blogs.msdn.com/edglas/archive/2009/06/13/increasing-the-roi-of-our-automation.aspx

Have a read.

Coded UI Test from Microsoft Test & Lab Manager

2009-05-26T13:16:46Z

After you have created a Coded UI Test and added it to a Team Build, you can run the test from a Microsoft Test & Lab Manager (MTLM). In this post, i will describe the steps to enable this.

NOTE: When run from MTLM, coded UI tests must be run using an environment like any other automated tests. There is no option to run coded UI test locally unless your test agent and controller are installed locally.

Step 0: Run the Test agent from the command line.

a. On the Visual Studio Team Test Agent box, Open the Services Management Console.

b. Stop the Visual Studio Team Test Agent.

c. Run the Visual Studio Team Test Agent from the command line.

Step 1: Associate the Coded UI Test to the Test Case.

a. In Visual Studio, Open the Coded UI Test Project.

b. Open the Test Case from Team Explorer.

c. Navigate to the Associated Automation tab.

d. Click on … button next to Automated Test Name & Choose the

e. Choose the CodedUITestMethod and save the test Case.

Step 2: Setup the environment for running a Coded UI Test.

a. In Microsoft Test & Lab Manager, Navigate to the Lab Center and choose Controller tab. Add a new Controller.

Save & Close the Test Agent Controllers activity.

b. Navigate to the Environment tab and create a new Physical Environment.

Add the Desktop Client Role.

Assign the available machine to this role.

Finish the activity.

c. Navigate to the Test Settings tab and create a new Test Settings.

Choose to Run tests using an environment.

Associate the environment created in the previous step.

Finish the activity.

d. Navigate to the Organize Center & choose Test Plans tab.

Create a new Test Plan and set the Automated Test Settings to the Test Settings created in the previous step.

Also choose the Build Candidates and assign a Build to the plan.

NOTE: the Build Quality can be set for a build by opening it in Visual Studio Team Explorer.

Save and close the Test Plan.

e. Navigate to the Testing Center and click on Plan activity.

Add the Test Case (seen in Step 1) to the new Test Plan.

Step 3: Run the Coded UI Test from Microsoft Test & Lab Manager

Navigate to the Testing Center & choose Test tab.

Right click on the Test Case and choose Run.

The status of the Test Run is shown in MTLM.

The Coded UI Test will be run on the specified environment.

Coded UI Test in a Team Build

2009-05-26T10:28:32Z

In this post, i will describe the steps required to add a Coded UI Test in a Build Definition.

Pre-requisites:- An existing Coded UI Test Project, A Connection to Team Foundation Server

0. On the Build Server, run the Team Build Service Host from the command line.

0.a. Open the services management console.

0.b. Stop the Visual Studio Team Foundation Build Service Host.

0.c. Open a command window and start the Team Build Service Host.

1. In the Solution Explorer, right click on the Coded UI Test Solution and choose Add Solution to Source Control.

2. Choose the folder in which you want to add this solution.

3. In the Pending Changes window, add a Comment and check in the code.

4. Open Team Explorer and Create a New Build Definition

5. Specify a name for the Build.

6. Leave the Trigger & Workspace tabs unchanged. [The default values are sufficient]

7. In the Build defaults tab, specify the Test Controller & a drop folder for the build.

8. In the Process tab, specify Projects to Build (add the project that you checked in in step 3), Test Assembly Filespec (*test*.dll) & Test Metadata files (choose the vsmdi file that you checked in in Step 3).

9. Save the Build Definition and Queue a new build.

10. In the Build Explorer, you can see the status of the Queued Builds. Double click on a Build to see its log.

In the detailed log, you can see the Coded UI Test getting compiled and then run.

No more UI regressions

2009-05-26T09:08:46Z

During the course of a Application Development Lifecycle, software goes through many iterations. Frequently, a change in one part of the software impacts another part and the developer remains blissfully unaware. Regression testing seeks to verify that existing functionality is not impacted by new changes. Automated Regression testing is a key tool for both the developer and the tester to ensure Product Quality.

Visual Studio Team System 2010 introduces a new test type – Coded UI Test, which enables you to create automated UI tests which can then be added to a regression test suite. Coded UI Tests may be run as part of a Build Verification Test suite, thus giving the developer immediate feedback on any UI regressions. The developer can run these UI Tests before his checkin and ensure that there are No more UI regressions.

A Coded UI Test can be created very easily with the tooling support provided in VSTS 2010. See links below for step by step guidance.

Generally initial phases in UI Testing is manual. Visual Studio Team System 2010 allows you to reuse the test artifacts created by manual tester. You can create a Coded UI Test from an action recording created by the manual tester.

Coded UI Tests may be created in either Visual Basic or C#. Multiple platforms can be tested with Coded UI Test. The platform support matrix is shown below.

Once a Coded UI Test is checked into source Control, you can easily add it into a Build Definition. The Build Definition below compiles a Coded UI Test Project and then runs its whenever a build is executed.

It is possible to associate a Coded UI Test to a Test Case. You can then run this test case from Microsoft Test & Lab Manager.

Coded UI Tests may be run from the command line also.

Summary:

Visual Studio Team System 2010 allows you to eliminate UI regressions by providing

rich tooling and a powerful API for creating a Coded UI Tests.
multiple easy modes of running Coded UI Tests.

TechEd India 2009

2009-05-15T13:58:05Z

I was at TechEd India 2009 for the past two days. There were some really interesting talks.

Amit Chatterjee did a talk on Visual Studio Team System. There is a segment in his demo for “No more regressions” where he showed Coded UI Test in action.

I also attended talks on “New features in WPF 3.5” and “Performance Optimizations in .NET”. Some really cool features in WPF.

We had a Technology Tent for Visual Studio Team Test. There were demos running continuously from 9AM – 1PM. There were a lot of participants keenly interested and excited about the new features coming out in VSTS 2010. Everyone is anxiously waiting for Beta1.

Here is the Beta 1 landing page for Visual Studio Team System: http://go.microsoft.com/fwlink/?LinkId=151798

Coded UI Test on 10-4

2009-05-08T11:58:29Z

MSDN Channel 9’s 10-4 program now has an episode on Coded UI test.

Watch it at http://channel9.msdn.com/shows/10-4/

Excerpt

Episode 18: Functional UI Testing

In this 18^th episode of 10-4 we look at a new type of test coming in Visual Studio Team System 2010 known as the coded UI test. Coded UI tests can be created to automatically navigate through your application's UI, which in turn can be used to verify that the paths your users might take through your application are working properly. You can also add validation logic along the way to verify the properties of objects within the UI. Much like unit tests can quickly surface regressions on a method or function level, coded UI tests can bring the same level of rapid automated testing capabilities to the UI layer.

This demo is based on an early build of Visual Studio Team System 2010 Beta 1.

More on Data Driving Coded UI Tests

2009-04-16T13:11:47Z

In the previous post, i described how we use a CSV file to data drive a Coded UI Test. The functionality is achieved by adding the following Data Source attribute to Coded UI Test.

[DataSource("Microsoft.VisualStudio.TestTools.DataSource.CSV", "|DataDirectory|\\data.csv", "data#csv", DataAccessMethod.Sequential), DeploymentItem("data.csv"), TestMethod]

The Data Source Wizard helps you to construct this attribute and insert it into the code.

For using a Excel file as the data source, use the following Data Source attribute.

DataSource("System.Data.Odbc", "Dsn=Excel Files;Driver={Microsoft Excel Driver (*.xls)};dbq=|DataDirectory|\\Data.xls;defaultdir=.;driverid=790;maxbuffersize=2048;pagetimeout=5;readonly=true", "Sheet1$", DataAccessMethod.Sequential), TestMethod]

NOTE: if you are using the Data Source Wizard, you may have to modify the generated attribute definition to match what is shown in the line above.

IN the above Data Source Attribute, you can change the file to a Excel 2007 file (.xlsx) and it will work.

If you hit some issues while data driving, I recommend Troubleshooting Data-Driven Unit Tests. The tips on this page helped me to fix most of the issues i encountered.

For Data driving using an XML file, the data source attribute created by the Wizard will work. A sample XML content is shown below.

<?xml version="1.0"?>
<Iterations>

</Iterations>

I have two iterations in this XML.

Data driving Test Cases authored in Camano

When a test case is authored in Camano, we can data-drive a step by prefixing the parameter with the ampersand sign (@)

See below screenshot of a data-driven Test Case authored in Camano. Note that @Zip, @FoodType , @Meal, @Within & @Restaurant are used to indicate data driven parameter values. The actual values are entered in the Parameter Values table below.

In this case the Data is stored in the Test Case itself.

When a Coded UI Test is generated from this Test Case, the following Data Source Attribute is added.

[DataSource("Microsoft.VisualStudio.TestTools.DataSource.TestCase", "http://vlm13261329:8080/tfs/DefaultCollection;Agile", "30", DataAccessMethod.Sequential), TestMethod]

This is a new Data Source we have added in Visual Studio 2010. It takes the following arguments

1. http://vlm13261329:8080/tfs/DefaultCollection;Agile – The Team Foundation Server & the Team Project

2. 30 – the Id of the Test Case

NOTE: Coded UI Test can be generated from a Test Case only if it has an action recording associated with it. This is done by default when you run the Test in “Start Test & Record” mode in Test Runner.

Data Driving Coded UI Tests

2009-03-17T02:47:49Z

Frequently, we have to repeat a test with different data values. This ‘data-driving’ is made very easy in Coded UI Test. In the Tutorial, we created a Coded UI Test to verify the addition of two numbers in the calculator. Let us now see how we can convert it into a data-driven test.

Step 1:- Create the Coded UI Test – See Tutorial

Step 2:- Create the data sets. Coded UI Test supports multiple data sources. The data sets may be defined in a CSV (comma separated values) file, an Excel worksheet, an XML file, database table or from a test case on TFS. For this walkthrough, we will use a CSV file with the following data.

Add1	Add2	Sum
7	2	9
5	2	7
3	2	5

Step 3:- Add the Data Source binding in Coded UI Test.

a. Open the Test View window (from Test -> Windows -> Test View

b. Choose the Coded UI Test that we created and from the context menu click Properties.

c. In the Properties Window click on the button in Data Connection String property to create a new Data Connection.

d. This brings up the New Data source Wizard

e. Choose CSV file and click Next

f. Select the CSV file that we created in Step 2. A preview of the contents is shown in the Wizard.

g. Click Finish. A prompt comes up to add the Data file into the project.

h. Click Yes.

i. A Data Source attribute is added to the Coded UI Test.

[DataSource("Microsoft.VisualStudio.TestTools.DataSource.CSV", "|DataDirectory|\\data.csv", "data#csv", DataAccessMethod.Sequential), DeploymentItem("data.csv"), TestMethod]

Step 4:- Use the data in the Coded UI Test.

a. Open the Recorded methods file. The following snippet of code clicks on Button 7 in calculator.

// Click '7' button

WinWindow item7Window = new WinWindow(calculatorWindow);

#region Search Criteria

item7Window.SearchProperties.Add("ControlId", "131");

#endregion

WinButton item7Button = new WinButton(item7Window);

#region Search Criteria

item7Button.SearchProperties.Add("Name", "7");

#endregion

Mouse.Click(item7Button, new Point(26, 12));

b. Change the highlighted line to

item7Button.SearchProperties.Add("Name", testContext.DataRow["Add1"].ToString());

NOTE: Test Context object contains a handle to all the Data that is present in the Data Source. We can reference it with the column name (e.g:- “Add1”)

c. Similarly the following code snippet clicks Button 2 in calculator

// Click '2' button

WinWindow item2Window = new WinWindow(calculatorWindow);

#region Search Criteria

item2Window.SearchProperties.Add("ControlId", "126");

#endregion

WinButton item2Button = new WinButton(item2Window);

#region Search Criteria

item2Button.SearchProperties.Add("Name", "2");

#endregion

Mouse.Click(item2Button, new Point(23, 11));

d. Change the highlighted line to

item2Button.SearchProperties.Add("Name", testContext.DataRow["Add2"].ToString());

e. Open the Coded UI Test file. The following line verifies the result.

// Validate UIItemEdit.Text AreEqual '9. '

Assert.AreEqual("9. ", UIMap.UICalculatorWindow.UIItemWindow.UIItemEdit.Text);

f. Modify this line to

StringAssert.StartsWith(UIMap.UICalculatorWindow.UIItemWindow.UIItemEdit.Text, TestContext.DataRow["Sum"].ToString());

NOTE:- We changed the Assert to a StringAssert, the comparator to StartsWith & reversed the order of the arguments.

Step 5:- Run the data driven test.

Right click inside the Coded UI Test Method and choose ‘Run Tests’

The test will run 3 times (as many iterations as there rows in the Data Source). The Test Results will show each iteration details.

You have seen in this walkthrough how to create a data driven tests. If the Test Case is authored in Camano, there is an even simpler way to make it data-driven. More about this workflow in the next article.

Distributed Coded UI Tests

2009-03-03T11:20:25Z

Coded UI Tests can be run in a distributed fashion. It leverages the existing Load Test architecture. Read the Load Test Team blog for more information.

Since Coded UI Tests always interact with the UI, the following change has to be made for the Agent on which they has to be run.

UI Testing on an Agent

If you want to run a test that has a UI or interacts with the desktop or user settings, you will need to use QTAgentServiceUI on the agent instead of QTAgentService.exe. QTAgentServiceUI works exactly like QTAgentService, except that it runs as a user process rather than a service. We recommend you configure your agent to automatically logon as a test user, and then in the startup for that user run QTAgentServiceUI.bat. This bat file simply runs QTAgentServiceUI over and over, so that if the agent service dies it will be automatically restarted.

In the Coded UI Test Project, double click on the testsettings file.

In the Execution Criteria, choose Execute Tests remotely.

Select the name of the controller to use for remote test execution.

If there are multiple agents associated with the controller, we can filter the agents on which the test has to be run based on properties. In the screenshot above, i am using a property named CodedUITest to differentiate agents. I will set this property to true for the agent on which I want to run the Coded UI Test. (Remember this has to be run as the batch file and not as the service).

In the screenshot above, see how i have set the property for my agent.

Hand-coding a Coded UI Test

2009-02-12T13:57:41Z

1. In Visual Studio Team System 2010, click on Test menu and choose New Test

2. In the Add New Test dialog, choose Coded UI Test and click OK.

NOTE:- You can choose to create a Visual C# test project or a Visual Basic test project.

3. In the New Test Project dialog, change the Test Project name and click Create.

4. In the Coded UI Test dialog, click Don’t generate code

5. All the required references are added and Coded UI Test file is opened in the editor.

6. Now you can start writing Code for a test.

For this tutorial, we will write code for the following test.

Test Steps

a. Navigate to http://live.com

b. Search for "MSFT"

c. Verify that MoneyCentral link to Microsoft is present in the results.

We will write the code in CodedUITestMethod1.

The following statement launches the browser and navigates to live.com.

BrowserWindow browserWindow = BrowserWindow.Launch(new System.Uri(http://live.com));

BrowserWindow class provides multiple overloads of the static Launch method.

You can attach to an existing browser window using the static FromProcess method.

Another option is to Search for an existing Browser based on its properties. IN the following snippet, i search for a browser containing “Blank Page” in its name.

browserWindow.SearchProperties.Add(new PropertyExpression(UITestControlProperties.Common.Name, "Blank Page", PropertyExpressionOperator.Contains));

browsertWindow.Find();

The following code block finds the edit box with ID = sb_form_q on the live.com page. It sets the Text property of that Edit box to “MSFT”.

It then searches for the button with ID = sb_form_go and clicks it.

// Type 'MSFT' in 'q' text box

UITestControl qEdit = new UITestControl(browserWindow);

qEdit.TechnologyName = "Web";

qEdit.SearchProperties.Add(HtmlProperties.Edit.ControlType, ControlType.Edit.Name,

HtmlProperties.Edit.Id, "sb_form_q");

qEdit.SetProperty(HtmlProperties.Edit.Text, "MSFT");

// Click 'Search' button

UITestControl searchButton = new UITestControl(browserWindow);

searchButton.TechnologyName = "Web";

searchButton.SearchProperties.Add(HtmlProperties.Button.ControlType,ControlType.Button.Name,

HtmlProperties.Button.Id, "sb_form_go");

Mouse.Click(searchButton);

Note that both the edit box and button are represented by the same class UITestControl. This class can be used to refer to any control on the user interface.
The constructor for UITestControl class accepts an argument which specifies the searchLimitContainer. The search for the UITestControl will be limited to all the child controls of searchLimitContainer. In the code above, we are limiting search to all children of browserWindow.
Since Coded UI Test supports multiple technologies (Web, MSAA, UIA), we have to specify the technology name for the control. In the code above we set the technology name to Web. If a technology name is not specified, the search is done in the technology of the search limit container. In this example, it would have been in the technology of browserWindow, which is MSAA.
We then specify SearchProperties which will be used to find the control. In the code above, we search based on ControlType and Id. It is possible to discover the various properties of a control using the HtmlProperties class. HtmlProperties.Edit will contain all properties applicable to an edit box.
There is a Find() method on UITestControl. Normally this is done implicitly whenever an action is performed on a control. In the code above, the Find method for qEdit is called from within the SetProperty method.
Mouse actions are performed using the Mouse class. It provides static methods for all possible operations with a Mouse. Similarly there is a Keyboard class for keyboard operations.

The next step is to validate the results. The following code snippet does that.

// Verify HREF property of mSFTStockQuotefHyperlink

UITestControl MSFTStockQuoteHyperlink = new UITestControl(browserWindow);

MSFTStockQuoteHyperlink.TechnologyName = "Web";

MSFTStockQuoteHyperlink.SearchProperties.Add(HtmlProperties.Hyperlink.ControlType, ControlType.Hyperlink.Name);

MSFTStockQuoteHyperlink.SearchProperties.Add(HtmlProperties.Hyperlink.InnerText,"MSN Money",PropertyExpressionOperator.Contains);

string propMSFTStockQuoteHyperlinkHref = ((string)(MSFTStockQuoteHyperlink.GetProperty(HtmlProperties.Hyperlink.Href)));

StringAssert.StartsWith(propMSFTStockQuoteHyperlinkHref, http://moneycentral.msn.com/detail/stock_quote?symbol=MSFT);

This searches for a Hyperlink which contains MSN Money in its inner-text. It verifies the Href property of the hyperlink.

Assert and StringAssert classes can be used for validation.

The final Coded UI Test Method should look like below.

7. Right click inside the Coded UI Test Method and choose Run Tests.

8. The code is compiled and then the test is run.

9. All actions recorded earlier will now be played back.

Frequently Asked Questions

2009-02-09T13:18:42Z

I have started the Coded UI Test Recorder. It is not recording any action I perform on my application. Why?

Verify that

- The app is not running at higher privilege than the VS. (E.g. VS running as normal user but app running as admin.)

- The app is not running from network path.

If you are still facing an issue, locate UITestLog.htm file in %temp%\UITestLogs\LastRun and send it to rnptalk.

Thanks GautamG for this tip.

2. Why am i getting a “ControlNotFoundException” when i perform an action on a UITestControl?

- Verify that the SearchProperties of the UITestControl can be used to uniquely identify a control.

- Verify that the combination of FilterProperties & SearchProperties will uniquely identify a control. If there are multiple qualifying candidates from the SearchProperties, FilterProperties are used to disambiguate them.

- verify that the SearchProperties are spelled correctly. The recommended way to specify the name of a search property is to use the *properties class hierarchy. e.g:- HtmlProperties.Button.DisplayText, WinProperties.Edit.Text .

NOTE:- If an invalid name is specified in SearchProperties, it will throw ControlNotFound exception. If an invalid property is used in FilterProperties, it will be ignored. If an invalid Property is used in GetProperty/SetProperty, it will throw a NotSupportedException.