While creating the coded UI test, the Test Builder generates multiple files to map the user interface, test methods, parameters, and assertions for all tests.

CodedUITest1.cs

The name of this file is generated based on the name of the test that is created. This file can be modified any time. This file contains one public class with the name CodedUITest1, with the CodedUITest attribute added to the class so that this class can be recognized as a test class. The name CodedUITest1 is the default name chosen by the system. If this file already exists, the system increments the number associated with the name and then creates the file with the new name.

The class also contains two default properties, TestContext and UIMap.

The following screenshot shows the default properties:

There are two additional methods which are commented out by default. A region titled Additional test attributes contains these two optional methods, as shown in the following screenshot:

The MyTestInitialize() method is called once before any other test methods during the Test Run. This is useful for initializing the tests and is identified as the initializer using the attribute TestInitialize. Similarly the method MyTestCleanup() method is called once after all the tests have been called, and this method is identified using the attribute TestCleanup().

public void BrowsetotheEmployeeDetailsApplication()
public void OpentheInsertEmployeeDetailsPage()
public void Submitthedetails()

/// <summary>
/// BrowsetotheEmployeeDetailsApplication – Shared Steps 14 – 
  Use 'BrowsetotheEmployeeDetailsApplicationParams' to pass 
    parameters into this method.
/// </summary>
public void BrowsetotheEmployeeDetailsApplication()
{
  #region Variable Declarations
  HtmlHyperlink uIEmployeeHyperlink = 
    this.UIBlankPageWindowsInteWindow.
      UIEmployeeMaintenanceDocument.UIEmployeeHyperlink;
  #endregion

  // Go to web page 'http://localhost:3062/' using new browser 
    instance
  this.UIBlankPageWindowsInteWindow.LaunchUrl(new System.Uri
    (this. BrowsetotheEmployeeDetailsApplicationParams.
      UIBlankPageWindowsInteWindowUrl));

  // Click 'Employee' link
  Mouse.Click(uIEmployeeHyperlink, new Point(17, 9));
}

UiMap.uitest

This is an XML file which represents the structure of the coded UI test recording. These include the actions, properties, and methods of the classes. The UIMap.Designer.cs file contains definitions of all the methods that are generated by the coded UI Builder. As the UIMap test files are generated by the Test Builder, it is not advisable to edit the files directly, but rather to use the UIMap editor to work with the methods. Every time there is a change to the recording or to the controls in the recording the file is regenerated and overwrites the custom code, which is the reason why we do not modify the generated code. The following screenshot shows the editor with the list of recorded actions and the corresponding UI controls. The Click 'Employee' link is the action which corresponds to the UIEmployeeHyperLink.

The editor contains options to delete a method, rename the method, set properties, split into a new method, move code to the UIMap.cs file, insert delays, and locate controls. The following screenshot shows the properties window for one of the user actions - in this case, to go to the web page:

The other main functionality in the editor is to move the code to the UIMap.cs file. Initially the UIMap.cs file would be an empty class without any implementation. If there is any customization required, it is not advisable to directly edit in the designer.cs file, but the method can be moved to the UIMap.cs file and then the customization can be done. Choosing the Move code to UIMap.cs option provides a warning saying the method will be removed from the UIMap.uitest file and moved to UIMap.cs and you will not be able to edit the method using coded UI test.

Choosing the Move code to UIMap.cs option provides a warning saying the method will be removed from UIMap.uitest and moved to the UIMap.cs file and you will not be able to edit the method using coded UI test, as shown in the following screenshot:

Once you confirm the code move, the method is removed from UIMap.uitest and copied to UIMap.cs and is ready for customization.

The coded UI test that was created previously is for a given set of data captured during test recording. Later on, the test may be required not only for one set of data but for different sets of data and for multiple times. To achieve this, we parameterize each field to get data from a data source during testing. Each row of data in the data source is an iteration of coded UI test. When generating methods or assertions for the coded UI test, all constants in the recorded methods are parameterized into parameter classes. In the previous code example, there is a BrowsetotheEmployeeDetailsApplication method as shown in the following code:

/// <summary>
/// BrowsetotheEmployeeDetailsApplication – Shared Steps 14 – 
  Use 'BrowsetotheEmployeeDetailsApplicationParams' to pass 
    parameters into this method.
/// </summary>
public void BrowsetotheEmployeeDetailsApplication()
{
  #region Variable Declarations
  HtmlHyperlink uIEmployeeHyperlink = 
    this.UIBlankPageWindowsInteWindow.
      UIEmployeeMaintenanceDocument.UIEmployeeHyperlink;
  #endregion

  // Go to web page 'http://localhost:3062/' using new 
    browser instance
  this.UIBlankPageWindowsInteWindow.LaunchUrl(new System.Uri
    (this. BrowsetotheEmployeeDetailsApplicationParams.
      UIBlankPageWindowsInteWindowUrl));

  // Click 'Employee' link
  Mouse.Click(uIEmployeeHyperlink, new Point(17, 9));
}

For the above method the Coded UI Test Builder creates the class as shown in the following code and adds fields to the class for every constant value used while recording.

    public HtmlHyperlink UIEmployeeHyperlink
    {
      get
      {
        if ((this.mUIEmployeeHyperlink == null))
        {
          this.mUIEmployeeHyperlink = new HtmlHyperlink(this);
          #region Search Criteria
          this.mUIEmployeeHyperlink.SearchProperties
            [HtmlHyperlink.PropertyNames.Id] = 
          "ContentPlaceHolder1_Menu1_HyperLink1_2";
          this.mUIEmployeeHyperlink.SearchProperties
            [HtmlHyperlink.PropertyNames.Name] = null;
          this.mUIEmployeeHyperlink.SearchProperties
            [HtmlHyperlink.PropertyNames.Target] = null;
          this.mUIEmployeeHyperlink.SearchProperties
            [HtmlHyperlink.PropertyNames.InnerText] = "Employee";
          this.mUIEmployeeHyperlink.FilterProperties
            [HtmlHyperlink.PropertyNames.AbsolutePath] = 
              "/Employee/List.aspx";
          this.mUIEmployeeHyperlink.FilterProperties
            [HtmlHyperlink.PropertyNames.Title] = null;
          this.mUIEmployeeHyperlink.FilterProperties
            [HtmlHyperlink.PropertyNames.Href] = 
              "http://localhost:3062/Employee/List.aspx";
          this.mUIEmployeeHyperlink.FilterProperties
            [HtmlHyperlink.PropertyNames.Class] = null;
          this.mUIEmployeeHyperlink.FilterProperties
            [HtmlHyperlink.PropertyNames.ControlDefinition] = 
              "id=ContentPlaceHolder1_Menu1_HyperLink1_";
          this.mUIEmployeeHyperlink.FilterProperties
            [HtmlHyperlink.PropertyNames.TagInstance] = "5";
          this.mUIEmployeeHyperlink.WindowTitles.Add
            ("Employee Maintenance");
          #endregion
        }
        return this.mUIEmployeeHyperlink;
      }
    }
    #endregion
  
    #region Fields
    private HtmlHyperlink mUIEmployeeHyperlink;
    #endregion
  }

Now the required test and test files are created. Let us create a data source in the form of a .csv file and use it for the coded UI test. The sample data in the .csv file is shown in the following screenshot:

Select the test method from the class file and insert the data source attribute directly in the code in the line immediately above the method. The earlier Version of Visual Studio has the data source wizard to associate the data source to the test method. But VS 2012 does not have the wizard. Just add the data source attribute and start using the data columns and rows as follows:

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

Save the changes to the CodedUITest1.cs file. Now right-click the coded UI test in the code editor and choose Run Unit Test. After the test is run, the overall Test Result for all iterations is displayed in the Test Results window.

If the CodedUITest1 test is run now, the test would run for each row in the data source. As there are three rows in the data source the test would run three times. Even if one of these tests fails, the entire Test Result would fail.

What is shown in the preceding screenshot is only the CSV data source but there are multiple other data sources, such as XML file, Microsoft Excel, test cases in Team Foundation Server, and SQL Express.

Sometimes some kind of validation is required for UI controls. For example, some of the controls in the UI should not be null. Use the Coded UI Test Builder to generate code for the validation method that uses an assertion for a UI Control. Add the UI control to the existing UI map file and generate the code to the existing coded UI test file.

Open the Test Project and the coded UI test file, which is named CodedUITest1.cs. In the code file place the cursor on CodedUITestMethod1(), right-click and select the option Generate code for Coded UI Test and then choose Use Coded UI Test Builder.

The Coded UI Test Builder opens with menu options for adding controls and validations. Open the application and then open the UI page for which we need to add the validation logic. Keeping the UI open, simply drag-and-drop the crosshair from the Test Builder to the control on the UI. The other option is to select the control then keep the mouse pointer on the UI Control while pressing the Windows logo key + I to select the control at the mouse pointer.

After selecting a control, the Add Assertions screen opens for the selected control. The window displays all the properties of the selected control. Select the property of the control to be validated and then click on the Add Assertion option. The following image shows the window to select the assertion type, add the Comparison Value for the validation, and to provide the Message on Assertion Failure.

Just for testing purposes, let's add an IsNotNull assertion type for the first name UI control for the Text property of the control. Click on Ok to add the assertion to the test. Keep adding assertions for all validations required for the controls. Once all required assertions are added, click on the Generate code option in the Test Builder and provide name for the assert methods that were added. This option automatically creates the code for assertions and adds the method definition and method calls to the corresponding files.

All assertion method definitions are added to the UIMap.Designer.cs file and the method is called from the main method CodedUITestMethod1() in the CodedUITest1.cs file. The following code shows the code for the assertion generated in the designer file:

/// <summary>
// This is the assert method for validating the null value 
  for employee first name
/// </summary>
public void AssertMethod2()
{
  #region Variable Declarations
  HtmlEdit uIFirst_NameEdit = 
    this.UIEmployeeWindowsInterWindow.UIEmployeeDocument1.
      UIFirst_NameEdit;
  #endregion

  // Verify that the 'Text' property of 'First_Name' 
    text box is not equal to 'null'
  Assert.IsNotNull(uIFirst_NameEdit.Text, 
    "The Employee First Name cannot be Null");
}

Now to test the assertion functionality, open the data source CSV file and empty the values for the first name of all the employees in the file. Navigate to CodedUITest1 from the Test Explorer window and run the test. As there are three rows in the data source, there will be three iterations of the test run, and all three will fail because the first name is null in all rows. The test is checking for a not null value in the first name field. So the entire test would fail because of the tests failure.

Now the required coded UI testing is successful. One difficulty in this type of code generation is the code maintenance. As we know that all the assertion codes and the validation methods are added to the UIMap class, there is chance of this class file growing to a larger size, if we keep on adding the controls and methods. To avoid this situation, multiple UIMap files can be generated.

The application can be grouped into modules or logical subsets, and each UIMap file mapped to one particular logical subset of the application. This logical grouping also helps the tester to work on an individual module without affecting other areas of the application. To create the logical grouping, first create a folder under Test Project. Then select the folder and create a new item of type Coded UI Test Map from the available templates as follows:

Click on Add after providing a name for the new Map file. The Coded UI Test Builder window will now appear after minimizing the Visual Studio window. Using the Test Builder, keep recording the actions and creating the validations for the UI controls. Make sure of adding controls and validation specific to the module for which the map file is created. Generate the code using the option in the Test Builder after completing the recording. You can see the new .uitest file and designer.cs files added to the test under the new folder. The following image shows the new UIMap files created under the new folder:

For any mapping that we create there are certain best practices to follow for easy maintenance and successful Test Results, such as: