Understanding the code generated by “Coded UI Test” – Part 1

This blog post has been updated to reflect changes in VS 2010 RC or later build. If you are on VS 2010 Beta 2, please upgrade before trying this post.  

This is Part 1 of two part series.  In this part we will focus on -

Why is generated code not a straight-line code?

In the Part 2, we will focus on -

How is generated code making reusability & customization easier?

So, why is generated code not a straight-line code?

While generating the straight-line code i.e. dumping everything in one method is the easiest thing for Coded UI Test, the tool is not doing that because in almost all cases that is not what you want.

The guidelines for code generation that we came up with (some based on the feedback received) was -

1. Encourage reusability of the test code. This is both for productivity and better maintenance.
2. Make customization of code easier for common scenarios like Data Driving.
3. Give full control on the code for advance operation.

Following through the above guidelines have made the generate code bit complex (and might look overwhelming to first time users). In this blog, I will explain the generate code and how it is doing against the above guidelines.

Before proceeding further, let me take an example test case to automate. Say I am a tester with the Bing Search team. One of the P0 tests for me would be to ensure when searched for word “bing”, the Bing Search comes as the first link. The test steps for this would be –

1. Launch IE and go to Bing
2. Search for “bing”
3. Verify the first link
4. Close Bing

Using the tool and recording each step as a separate method, the final code in the TestMethod would look something like this -

 [TestMethod]
public void SearchBingTest()
{
    this.UIMap.LaunchBing();
    this.UIMap.SearchBing();
    this.UIMap.VerifyFirstLink();
    this.UIMap.CloseBing();
}

The complete code is attached as BingTestGeneratedCodeAsIs.zip.

At this point, let us drill down into understand the code.  The following files are generated by the tool -

File	Description	Can this be edited?
BingSearchTest.cs	The default name for the file is CodedUITest1.cs. This is the file in which all the Test Methods are added.	YES
UIMap.uitest	An XML file has all the information about the recording including actions, objects and data.	NO today. In future, we may have editor for this file.
UIMap.Designer.cs	This file contains the code generated by the tool based on the recording in UIMap.uitest file (a.k.a. code behind file).	NO. Any edits to this will be lost.
UIMap.cs	The main class generated by the tool is UIMap. This is partial class and is split into UIMap.Designer.cs  and UIMap.cs. While UIMap.Designer.cs contains code generated by the tool and should not be edited, the UIMap.cs file is the place where you would place all your customization. More on this later.	YES

Going by code generated by classes, there are 4 sets of classes -

Set of Classes	Description	Examples from above code
UIMap	The main class. This is partial class and is split across UIMap.cs and UIMap.Designer.cs files.	UIMap
UI Control classes	These classes represent the UI Controls used in the test. Each class has information about the properties to use to identify the control on the UI and about the child controls.	BingDocument, QEdit, SearchButton
Recorded\Assertion method Params classes	For each XYZ recorded or assertion (verification) method, a params class is generated which has fields mapping to the parameters used by that recorded or assertion method.  For data driving, these fields of params class are bounded to the data source.	LaunchBingParams, VerifyFirstLink-ExpectedValues

Once we have understood the basic concept, let us go into the next blog - How is generated code making reusability & customization easier?

BingTestGeneratedCodeAsIs.zip