The tutorial presented here utilizes a very simple WPF-based calculator. You can download this sample from this book's Web site at www.wrox.com. A version of the calculator written using Windows Forms is also available for you to try, although the source code and screenshots in this chapter will match that of the WPF version.

Begin by opening the solution for the SimpleWPFCalculator application. Press F5 to launch the application. You will notice that this is a very primitive application, but it will serve as a good example for learning how to work with coded UI tests. To use the application, simply enter an integer into each textbox and click the buttons corresponding to each math operation to generate the respective results, as shown in Figure 15-1. (In this example, the Subtract button was clicked.)

Figure 15.1. FIGURE 15-1

Create a desktop shortcut for your application to make it easier to launch when you are creating your tests. From within Windows Explorer, browse to the project directory where you unzipped the sample application. Open the SimpleWPFCalculatorinDebug folder and right-click on the SimpleWPFCalculator.exe file. Choose Create Shortcut, then drag the shortcut that is generated onto your computer's desktop. Confirm that double-clicking this shortcut launches the WPF calculator application.

Next, you will need a test project in which to house your coded UI test. Click File

Figure 15.2. FIGURE 15-2

You are now ready to add a coded UI test to your testing project. Right-click on the CodedUITestProject file from within Solution Explorer and choose Add

Figure 15.3. FIGURE 15-3

Choose the first option, "Record actions, edit UI map or add assertions." This option allows you to record a coded UI test from scratch by navigating through the application in the same manner that a user might. In the section "Creating Coded UI Tests Using Action Recordings," later this chapter, you will learn how to convert existing manual test cases into coded UI tests.

Visual Studio will now be minimized to make room for you to begin recording your test.

The Coded UI Test Builder now appears in the lower-right of your screen, as shown in Figure 15-4. The Test Builder is, as the name implies, a tool that can help you construct your coded UI tests. It is responsible for both recording actions you perform (for example clicking buttons, typing text, and so on), and for identifying controls and their properties that you wish to validate.

Figure 15.4. FIGURE 15-4

Minimize any open applications so that you can clearly see your desktop and the shortcut to the WPF calculator application. However, don't launch the shortcut yet. Click the Record button (the red, round circle on the left end of the toolbar) of the Test Builder when you are ready to begin recording your test.

The Test Builder should now resemble Figure 15-5, which indicates that it is recording your actions. At any time, you can click Pause (the leftmost button) to instruct Test Builder to stop recording your actions, and click the Record button when you are ready to resume.

Figure 15.5. FIGURE 15-5

You are now ready to begin recording the coded UI test by using the application in the same manner you would expect a user to. Launch the WPF calculator application by double-clicking on the desktop shortcut you created earlier. Type 20 in the first textbox, then type 10 in the second textbox, and click the Add button.

You can visually inspect the actions that the Test Builder has captured by clicking on Show Recorded Steps (the second button from the left) of the Test Builder. The window shown in Figure 15-6 will appear, showing you an easy-to-read list of the steps you have performed while recording your test. Note that you can pin this window if you'd like to have it remain visible while you are recording.

Figure 15.6. FIGURE 15-6

At this point in your test, you are ready to add some validation logic to confirm that the result of your addition operation is correct. But, before you add an assertion, you must convert the steps you have performed so far into source code. Do so by clicking on Generate Code (rightmost button) within the Test Builder.

The dialog shown in Figure 15-7 will prompt you for the name of the method you want to create within your coded UI test. You should use descriptive method names to make it easier to understand your generated code. Type EnterDataAndClickAdd; then click "Add and Generate" to resume building your coded UI test. The Test Builder will now convert your recorded steps into source code, which is then added to your Visual Studio project files. You will inspect this code later.

Figure 15.7. FIGURE 15-7

You can now add assertion logic to validate the properties of one or more controls. The Test Builder allows you to easily select the control you wish to validate. Do so by clicking and dragging the crosshair icon from the Test Builder onto the bottommost textbox of the calculator. As you hover over controls and windows of your desktop and applications, you will notice that they become highlighted to indicate which control you are selecting. Once you have selected the bottommost textbox of the calculator, release your mouse button.

The properties for the TextAnswerEdit textbox you have selected will be displayed as shown in Figure 15-8.

Figure 15.8. FIGURE 15-8

You can also use the up/down/left/right arrows of this dialog to navigate through the control hierarchy. You don't need to do so for this test, but this is helpful for controls that are difficult to select using the crosshairs, or invisible controls (such as a panel that may be used a container for other controls).

For this test, you want to confirm that the number 30 (the sum of 20 plus 10) is properly displayed in the textbox. In the list of properties for this control, you will see that the Text property has a value of 30. Highlight this row, then click Add an Assertion (the second button from the left on the toolbar). Figure 15-9 will appear, allowing you to define the behavior of your assertion. Click the Comparator drop-down to examine your assertion choices. Accept the default value (AreEqual) for Comparator and the current value (30) for Comparison Value. Click OK. The Test Builder will display a message indicating that your assertion has been added.

Figure 15.9. FIGURE 15-9

You can examine all of the controls that have been captured as part of your coded UI test by clicking Show UI Control Map (the leftmost button on the toolbar). Figure 15-10 shows the controls that have been added so far. Note that, in addition to the controls you are validating via assertions, the controls you have used to navigate within your application have also been added here.

Figure 15.10. FIGURE 15-10

Click Generate Code from within the Test Builder (the rightmost button) to codify the assertion you just added. The dialog shown in Figure 15-11 will appear, prompting you to name the method that will correspond to your assertion. Name the method AssertAdd and click "Add and Generate." The Test Builder will now convert the assertion you defined into C# and insert this into your test project.

Figure 15.11. FIGURE 15-11

Now, click the Record button (leftmost button) in the Test Builder again to resume recording your test case. Click on the Subtract button in the calculator, and then click Generate Code (the rightmost button) in the Test Builder. Name this method ClickSubtract and click "Add and Generate."

Now, add another assertion by following the same steps you followed earlier. After dragging the crosshair onto the bottommost textbox in the calculator, you will see the expanded UI Control Map. The TextAnswerEdit control should be highlighted. Select the Text property and add an assertion stating that this property should now be equal to 10. Click on Generate Code and name the assertion AssertSubtract.

Repeat these steps for the multiplication and division functions. Name the methods for clicking those buttons ClickMultiply and ClickDivide, respectively. Name the corresponding assertions AssertMultiply and AssertDivide. Once you are finished, close the Test Builder, which will return you to Visual Studio.

From within Visual Studio, you can now examine the code that was generated by the Test Builder while you were recording your test actions and assertions. The file CodedUITest1.cs is the main execution harness for your test, and calls all of the action and assertion methods you defined earlier, as shown here:

[TestMethod]
public void CodedUITestMethod1()
{
 this.UIMap.EnterDataAndClickAdd();
 this.UIMap.AssertAdd();
 this.UIMap.ClickSubtract();
 this.UIMap.AssertSubtract();
 this.UIMap.ClickMultiply();
 this.UIMap.AssertMultiply();
 this.UIMap.ClickDivide();
 this.UIMap.AssertDivide();
}

To better understand what each underlying method is actually doing, you can examine the partial class file named UIMap.Designer.cs. Right-click on the EnterDataAndClickAdd method call and select "Go to definition." This method is defined as follows:

/// <summary>
/// EnterDataAndClickAdd - Use 'EnterDataAndClickAddParams'
/// to pass parameters into this method.
/// </summary>
public void EnterDataAndClickAdd()
{
    #region Variable Declarations
    WpfEdit textInput1Edit = this.DemoCalculatorWPFWindow.TextInput1Edit;
    WpfEdit textInput2Edit = this.DemoCalculatorWPFWindow.TextInput2Edit;
    WpfButton addButton = this.DemoCalculatorWPFWindow.AddButton;
    #endregion

    // Launch '%USERPROFILE%DesktopcodeduiuidemoSimpleWPFCalculatorinDebug'
       + 'SimpleWPFCalculator.exe'
    ApplicationUnderTest demoCalculatorWPFWindow = ApplicationUnderTest.Launch(
    this.EnterDataAndClickAddParams.DemoCalculatorWPFWindowExePath,
    this.EnterDataAndClickAddParams.DemoCalculatorWPFWindowAlternateExePath);

    // Type '20' in 'textInput1' text box
    textInput1Edit.Text = this.EnterDataAndClickAddParams.TextInput1EditText;

// Type '10' in 'textInput2' text box
    textInput2Edit.Text = this.EnterDataAndClickAddParams.TextInput2EditText;

    // Click 'Add' button
    Mouse.Click(addButton, new Point(48, 15));
}

This method is responsible for performing four distinct actions, as defined by the actions you recorded earlier. This method will first launch the application, then enter values into two textboxes, then click on the Add button. Notice, however, that the parameters for this method are defined elsewhere in this file. Scroll down to the class EnterDataAndClickAddParams:

/// Parameters to be passed into 'EnterDataAndClickAdd'
public class EnterDataAndClickAddParams
{

    public string DemoCalculatorWPFWindowExePath =
    "C:\Users\administrator.ONEBOX\Desktop\codedui\"
    + "uidemo\SimpleWPFCalculator\bin\Debug\SimpleWPFCalculator.exe";

    public string DemoCalculatorWPFWindowAlternateExePath =
    "%USERPROFILE%\Desktop\codedui\uidemo\SimpleWPFCalculator\bin\"
    + "Debug\SimpleWPFCalculator.exe";

    public string TextInput1EditText = "20";

    public string TextInput2EditText = "10";
}

The reason that the parameters are separated from the actual method doing the work is that this makes it easier to override the parameters with new values. This is very important when creating data-driven tests that will run multiple times, using different values each time. You will do this later in this chapter.

Notice that there are two slightly different values defined to describe from where the application under test will be launched, DemoCalculatorWPFWindowExePath and DemoCalculatorWPFWindow AlternateExePath. Whenever possible, Visual Studio will look for ways to make your tests more robust so that they are less prone to accidental failure. The actual values you have for your test will vary, based on where you stored your application. But, for this example, notice that Visual Studio stored both the absolute path to the executable and the relative path based on the %USERPROFILE% environment variable. This makes your tests more fault-tolerant in the event that your executable changes locations later on.

Also, notice that the Test Builder interpreted your test actions as launching an application executable, instead of double-clicking on that application's shortcut on your desktop. This is also a way of making your test more fault-tolerant. In the future, you might decide to delete or move the shortcut to the executable, but you are less likely to move the actual executable itself. Recording tests can be a relatively expensive investment, so Visual Studio will use tricks like this to make it less likely that you must re-record your tests later on.

You are now ready to run your test and confirm that everything was properly recorded. Do so by returning to the CodedUITest1.cs file and right-clicking anywhere within the CodedUITestMethod1() code block. Select Run Tests. Avoid using your mouse or keyboard while the text executes. If you have recorded your test properly, the calculator will launch, the values 20 and 10 will be inserted into the textboxes, and each of the four operation buttons will be exercised. When finished, the test results will be displayed as shown in Figure 15-12.

Figure 15.12. FIGURE 15-12

Congratulations! You have now authored your first coded UI test. But what if you want to test values other than 20 and 10? One approach would be to author new tests, each with their own values. But this would be very time-consuming. A better solution is to create a data-driven test by binding the values for this test case to a database or XML file.

The process of creating a data-driven coded UI test is very similar to that of creating a data-driven unit test. Start by opening the Test View window (Test

The New Test Data Source Wizard will launch, as shown in Figure 15-14. This wizard will help you bind your test to a database, an XML file, or a comma-separated value (CSV) file to use as a data source for creating a data-driven test. Select XML File and click Next.

Figure 15.13. FIGURE 15-13

Figure 15.14. FIGURE 15-14

The sample application for this chapter includes an XML dataset named calcdata.xml. The contents of this file are as follows:

<?xml version="1.0" encoding="utf-8"?>
<DataContextData>
  <DataContextRow InputValue1 ="10"
                  InputValue2 ="2"
                  ExpectedAddAnswer ="12"
                  ExpectedSubtractAnswer="8"
                  ExpectedMultiplyAnswer="20"
                  ExpectedDivideAnswer="5"/>
  <DataContextRow InputValue1 ="20"
                  InputValue2 ="10"
                  ExpectedAddAnswer ="30"
                  ExpectedSubtractAnswer="10"
                  ExpectedMultiplyAnswer="200"
                  ExpectedDivideAnswer="2"/>
</DataContextData>

Use the wizard to browse to this file. A preview of the data contained in this file will be displayed, as shown in Figure 15-15. Click Next.

Lastly, highlight DataContextRow in the final dialog page, as shown in Figure 15-16, and click Finish.

Figure 15.15. FIGURE 15-15

Figure 15.16. FIGURE 15-16

Visual Studio will offer to add your XML file as a deployment item within your solution. This makes it easy to version-control your test data source along with your tests. Click Yes.

You can now begin overriding the parameters that you recorded earlier by data-binding them to your XML data source. The architecture of coded UI tests makes it easy to do this from within one central location — the CodedUITest1.cs file. Modify the CodedUITest1 method by inserting the following highlighted lines.

this.UIMap.EnterDataAndClickAddParams.TextInput1EditText =
TestContext.DataRow["InputValue1"].ToString();
this.UIMap.EnterDataAndClickAddParams.TextInput2EditText =
TestContext.DataRow["InputValue2"].ToString();

this.UIMap.EnterDataAndClickAdd();
this.UIMap.AssertAddExpectedValues.TextAnswerEditText =
TestContext.DataRow["ExpectedAddAnswer"].ToString();
this.UIMap.AssertAdd();

this.UIMap.ClickSubtract();
this.UIMap.AssertSubtractExpectedValues.TextAnswerEditText =
TestContext.DataRow["ExpectedSubtractAnswer"].ToString();
this.UIMap.AssertSubtract();

this.UIMap.ClickMultiply();
this.UIMap.AssertMultiplyExpectedValues.TextAnswerEditText =
TestContext.DataRow["ExpectedMultiplyAnswer"].ToString();
this.UIMap.AssertMultiply();

this.UIMap.ClickDivide();
this.UIMap.AssertDivideExpectedValues.TextAnswerEditText =
TestContext.DataRow["ExpectedDivideAnswer"].ToString();
this.UIMap.AssertDivide();

The code you added will now override the values from each of the respective "ExpectedValues" methods within the UIMap.Designer.cs file by data binding the values to the corresponding columns within your XML data source.

Run your test again by right-clicking within your test method and selecting Run Tests. Your coded UI test will now execute twice — once for each row of the XML data source. When finished, the test results should indicate that 3/3 tests have passed successfully. This includes each data row, as well as the overall test.

You can now maintain the calcdata.xml file within your test project to add new rows of data. These rows will be used during future test runs, thus providing you with an easy way to grow your test coverage. Any time you make changes to calcdata.xml, you will need to rebuild your solution (Build

By now, you may have noticed that your test runs leave instances of the WPF calculator running once the tests have finished. You could have closed the calculator as the last step of your recorded test actions. The problem with this approach, however, is that if your test fails, then the remaining actions will not be executed.

You want a solution that will close the calculator every time, regardless of whether or not the test fails. Otherwise, your machine will become littered with multiple instances of the application you are testing. This can eventually bog down your test machine, and may even cause tests to fail if the application being tested can only include one running instance.

The solution to this problem is to wrap the application launch event with a using clause. The using clause will cause the application to automatically close once it has gone out of scope, regardless of whether or not the test passed.

Open the EnterDataAndClickAdd method within the UIMap.Designer.cs file. Cut (don't copy) the line that defines ApplicationUnderTest. Paste this line into the top of the CodedUITestMethod1 method. You will need to further qualify the references within the method arguments to specify that the parameters live within the UIMap partial class. Finally, encapsulate the ApplicationUnderTest definition within a using() clause, and encapsulate the rest of the CodedUITestMethod1 logic within curly braces, as shown here:

using (ApplicationUnderTest demoCalculatorWPFWindow =
ApplicationUnderTest.Launch
(this.UIMap.EnterDataAndClickAddParams.DemoCalculatorWPFWindowExePath,
this.UIMap.EnterDataAndClickAddParams.DemoCalculatorWPFWindowAlternateExePath))
{
 this.UIMap.EnterDataAndClickAddParams.TextInput1EditText =
 TestContext.DataRow["InputValue1"].ToString();
 ...
 this.UIMap.AssertDivide();
}

Now, when you run this test, the calculator will automatically be closed after each test run, regardless of whether or not that run succeeded. You have now created a UI test that is fully automated, robust, and data-bound.

You can cause your tests to fail by changing the values in the calcdata.xml file (for example, 1 + 1 = 3). However, you may notice that the test results after each test run will only report that a test failed; it won't tell you which assertion (addition/subtraction/multiplication/division) was responsible for the test failing. For coded UI tests with multiple assertions, it can be useful to know more about exactly which assertion caused the test to fail. You can easily enhance the assertion reporting by adding an additional argument to each assertion call.

Open the UIMap.Designer.cs file and find the Assert call you wish to modify. Simply add a third argument with the text that you would like to show if an assertion fails. The following example will display "Addition failed" in the test results if the assertion for the addition step fails:

Assert.AreEqual(this.AssertAddExpectedValues.TextAnswerEditText,
textAnswerEdit.Text, "Addition failed");

Another way of creating such a test would be to utilize the action recording from an existing manual test.