When recording Silverlight applications Test Studio needs to be smarter about what it records as the target element and the properties. For example, if you click on a TextBox Test Studio will record clicking on a Grid element which is contained underneath the main TextBox element. While technically the Grid element maybe topmost, it is very brittle and does not line up with how you build XAML applications.

It's brittle because Test Studio records a XamlPath for locating the Grid element. It ignored the AutomationID that is applied to the TextBox element the Grid is contained under. It would have been much smarter, more reliable, to record clicking on the TextBox element that has the AutomationID instead.

It also is confusing to a XAML developer. When you create your XAML file, you don't put a Grid element in your XAML. You put a TextBox in your XAML and apply an AutomationID property to that element. It's the Silverlight engine that is adding the Grid element underneath at runtime. Test Studio should be smart and recognize TextBox as "the lowest element" and target that instead of the automatically inserted Grid element.

Another way Test Studio is not very smart is building chained find expressions (find element A then underneath that find element B). It seems to always want to use a brittle XamlPath for element B. In one specific case there are two TextBox's that have the same AutomationID. One is located in the main display, the other is located in a popup child window. If you specifically target the TextBox contained in the popup child window, Test Studio records a find expression as find the child window having AutomationID X then use a brittle XamlPath to find element B. If instead it recognized that the AutomationID is unique within the context of the child window and record that AutomationID instead the test would be far more resiliant to UI changes in the application.