CUIT (Coded UI Tests) + MVVM -- Do I have to start naming all my controls now?

Question

Basically, with MVVM I have a lot of my controls unnamed because it isn't necessary to give a Name (or x:Name) to controls anymore.

But, looking into coded UI Tests it seems as if I might have to go through and name all my controls again? Or did I just misunderstand what I read and there is a MVVM friendly way of doing CUIT?

Despain

Coded UI tests for WPF are really half baked. There are a LOT of control vendors whose controls just won't work with Coded UI Tests. You may want to look into an alternative Test Suite (like Telerik's or Infragistic's) – Palstave

Well, that's more of an issue of CUIT/3rd party controls and not the .NET WPF controls which all have an AutomationPeer built for them. – Despain

True, but I've still faced lots of problems where my coded UI test just stops finding UI elements and I need to re-record. – Palstave

Either way, that is off topic to the actual question about finding controls that aren't named. – Despain

Answer 1

You can add automation ids from the System.Windows.Automation.AutomationProperties namespace instead of having to change the id of the controls. I'd recommend that over expecting the elements to stay in the same order as stoj says above, it would be very painful.

See a post I found on [using the automation id].1 Here are examples from his post:

<MyControl AutomationProperties.AutomationId="AnUniqueValue"/>
protected override string GetAutomationIdCore() 
{ 
    return (AutomationProperties.GetAutomationId(_owner));
}

Readiness

Answer 2

If you want to reliably interact with a control using recorded tests you will need to provide a name or id for the control. Without names your test will rely on the instance property which as you noticed depends on the location of the unnamed control in relation to other unnamed controls.

If your application is very static you can possibly get away with not having names, but moving controls might result in breakage. You will also run into problems with controls that are loaded dynamically because they can cause the instance values to change and your recorded actions may happen on the wrong control.

Don't get me wrong you can write CodedUI tests for applications without control names it will just be a major pain point and recordings will be unreliable.

Courtesan

Answer 3

Ok, so apparently having unnamed controls makes it very difficult to make changes that don't break Coded UI Tests. The generated code assigns editable text boxes based on the order they are written in the XAML, which means if I move controls around it breaks my Coded UI Tests.

I haven't fully explored the Search Criteria, but I assume that it is far more complicated to created a Coded UI Test with unnamed controls. Ah well, I guess Name/x:Name is going to be making a comeback.

Despain