We are back in Beta2 with a bunch of new stuff in Coded UI test for UI automation testers. First up, the code generation in Coded UI test has been changed to structure the code in a much more usable and intuitive way:

1. All the UI elements you interact with, whether part of recording or added from the UI control locator, all go into a single UI Map – a single collection of all the UI objects in your test. So, you can now edit objects from a single store

2. Every assertion you add is now a method in itself which takes parameters where you can define the expected value to assert on. So, you can now separate the test into logical actions and assertions

3. The recorded methods also have input parameters defined on them that help make data driving easier to do. So, you can now data drive the method by changing the values of the input parameters that go into the recorded method.

For example, if you were testing the new user sign up in hotmail.com and checking if a certain id’s availability is displayed correctly, you can record steps to open hotmail.com, go to sign up page, enter a particular id and press “check availability” button.

The coded UI test project generated has 4 files – the coded UI test .cs file (TestHotmail.cs) containing the test method, UIMap.uitest file which is an XML representation of all the UI elements and actions/assertions performed on each UI object, the UImap.designer.cs file which is the code-behind for the .uitest file containing code for the objects and actions, the UIMap.cs is a file containing a partial definition of the UImap class to help preserve user customizations to the test code.

TestHotmail.cs – contains the actual test method and invocations to recorded methods and assertions

[CodedUITest]

    public class TestHotmail

    {  [TestMethod]public void TestNewUserSignUp(){

            this.UIMap.GotoSignUpPage();

            this.UIMap.CheckAvailabilityOfId();

            this.UIMap.VerifyIdAvailable();

        }}

UIMap.designer.cs – contains the definitions of the recorded methods, assertions and UI objects. Plus also contains the parameter class definitions passed into each class

public partial class UIMap    {

        public void GotoSignUpPage()

        {    HtmlInputButton signupButton = this.SignInWindowsInterneWindow.HttploginlivecomlogiClient.SignInDocument.SignupButton;

            // Click 'Sign up' button

            Mouse.Click(signupButton, new Point(47, 11)); }

       public void CheckAvailabilityOfId()

        { HtmlEdit imembernameliveEdit = this.SignupWindowsLiveWinWindow.HttpssignuplivecomsiClient.SignupWindowsLiveDocument.ImembernameliveEdit;

            // Type 'anutthar' in 'imembernamelive' text box

            imembernameliveEdit.Text = this.CheckAvailabilityOfIdParams.ImembernameliveEditText;

           // Click 'Check availability' button

            Mouse.Click(checkavailabilityButton, new Point(88, 15));      }}

// Input parameter into the CheckAvailabilityOfId recorded method

    public class CheckAvailabilityOfIdParams

    {      public string ImembernameliveEditText = "anutthar";    }

Other than that, the CUIT builder has gone through a major redesign and morphed into a stack bar at the bottom of your screen with pop up dialogs for the control locator, actions viewer, generate code etc. More on that in the next post

We’ve also added support for virtualized controls in WPF. You will need to wait until the UI Automation 3.0 APIs are available to get this working though. But this should certainly help WPF programmers trying to write tests on their UI apps.

Go ahead, give CUIT a spin and tell us what you think…