Save Time, Money, and Your Sanity: Coded UI Testing for the Windows Phone – Part 2

This post is the continuation from Save Time, Money, and Your Sanity: Coded UI Testing for Windows Phone – Part 1.

With everything now installed, we can go ahead and get started.

Creating a Coded UI Test in 5 Easy Steps

As I mentioned previously, creating Coded UI Tests within Visual Studio 2013 are so easy, that even developers with little to no testing experience can setup a basic Coded UI test by following these simple steps:

  1. Add a new Coded UI Test Project within the Visual Studio solution that contains your Windows Phone 8.1 project.
  2. Identify the controls that will be included in your tests.
  3. Add assertions where it makes sense.
  4. Generate any necessary Assert methods.
  5. Create any necessary Test methods.

Step 1 - Adding the Coded UI Test Project

Ensure you have a Windows Phone 8.1 project loaded in Visual Studio, and that you have a Windows Phone 8.1 Emulator instance running. Deploy your Windows Phone 8.1 app to the Emulator instance.

Once you have a running Emulator with your app installed, you are ready to add a new Coded UI test to your Visual Studio solution. Simply right-click on the Visual Studio solution node, and select Add > New Project… from the context menu. Within the Add New Project dialog, select the Visual C# > Store Apps > Windows Phone Apps in the left pane to narrow down the list of templates. Select the Coded UI Test Project (Windows Phone) template from the list, as shown below.


Modify your Coded UI Test Project name, if you wish, then click OK to add the project to the solution.

When the project is initially added to the solution, you will receive the following prompt to give you the option to edit the UI Map or add assertions using the Coded UI Test Builder tool, or you can choose to manually edit the test, as shown below.


Be sure that the first option, Edit UI Map or add assertions, is selected and click OK.

You will notice that the Coded UI Test Builder now appears in the bottom, right corner of your screen:


With that in place, you have successfully added a new Coded UI Test Project to your Visual Studio solution!

Step 2 – Identifying the Controls

In order to create Coded UI Tests, it is important to identify which user controls you want to use in your tests, so that these controls are added to the UIMap object within the Coded UI Test Project. If this is your first time creating a Coded UI Test, you may find it helpful to quickly review the MSDN article, Anatomy of a Coded UI Test Project.

To add a control to the UIMap, ensure your app is running in the Emulator, then simply hover the mouse pointer over a control, and hit Ctrl + Shift + I. The target control will be highlighted, and then added to the UIMap. You can continue to select controls within the application that you wish to add to the UIMap, simply by repeating the following steps:

  1. Hover mouse over the control.
  2. Click Ctrl + Shift + I.

Your UIMap hierarchy, in the Add Assertions dialog, will display all of the controls you added. An example of this is shown below:


Now we’ve setup everything on the UI side. In the next post, we’ll be adding assertions and generating the assertion methods.

So far so good?

You with me so far? Have any questions? Please feel free to ask! Either post in the comments below, tweet me at @LoriBLalonde, or comment on the Facebook post on the Microsoft Developer Canada page. Try using Twitter (and make sure to use the #msdev hashtag) or Facebook – you never know, there may be others will want to join in the conversation as well.

Comments (6)

  1. Millstream says:

    I am trying to create asserts on a number of error providers for a smart client application – you know, those little red dots you have to hover over to get information? Unfortunatly, although I can drag a target over them, I can't seem to select them one at a time and there seems to be no valid property I can test against.

    I should mention: I'm using VS premium 2010.

  2. Lori says:

    Hi Millstream,

    Which type of smart client application are you developing Coded UI Tests against?  

  3. Millstream says:

    I'm not sure what you mean by 'type', is basically a windows application, it's just that you have to go download it through a browser window to open it.

  4. Lori says:

    Hi Millstream,

    It sounds like you're working with a Windows Forms application, and attempting to add an ErrorProvider to your CUI tests. In this case, when you add an ErrorProvider to your CUI test for Windows Forms, it appears as a WinClient object (ex: WinClient uIForm1Client = this.UIForm1Window.UIItemWindow.UIForm1Client). To perform a check against the displayed error message in your error provider, check the ToolTipText property on that WinClient object (ex: uIForm1Client.ToolTipText).

    I recommend checking out this post in the MSDN forums, which I believe is similar to what you are experiencing: "How to identify error provider in windows based application and get error messages for multiple text boxes?" –…/how-to-identify-error-provider-in-windows-based-application-and-get-error-messages-for-multiple-text

    If you are still experiencing issues, I recommend posting your question in the MSDN Test Tools in Visual Studio 2010 and 2012 forum (…/home) with more details about what you are experiencing with Coded UI Tests and the ErrorProvider control.

  5. Millstream says:

    Hello again,

    Yes, indeed this is for a windows form application. If I select the error provider using the target, It usually gives me the containing panel's text value for a <FriendlyName>, no matter what the error is which is unsuitable since I can't verify that the right error message appears in the right context.

    For instance, say a Year value is required in a textbox; if the textbox is empty – the message <Year is missing> should appear, if someone enters "-1", the message <Year is invalid> should appear. In this case FriendlyName would be the same in both instances.

    I have seen the discussion you are refering to in the past, unfortunatly, I don't think that person ever got a solution to their problem either.

    Best regards.

Skip to main content