Having WPF application with complex UI and want to write CodedUITest scripts for the same.
Since I am new to this, I need proper guidance/approach to write CodedUITest script.
It wont be possible to do everything using Record & Play stuff because we have some custom control exist on UI and can be changed any time.
I want to do this thing using C# code. facing issues while getting particular record from custom grid and identify control using C# code.
- What kind of properties should I have on control for easy identification in CodedUITest?
- Is it compulsary to give AutomationId to all the controls?
- What needs to be done for dynamic controls like Treeview and grid?
- How can I identify drag & drop type of window?
The theoretical side:
Coded UI Tests are made to do UI regression tests. Given a certain data your UI should react in a specific way. The idea of this king of tests, is that given the same data over and over the UI keep behaving the same way. In other words: if given a certain dataset your UI changes how reacts (based on the recordings), the test should break.
The Practical fact:
Coded UI tests are a testing framework, and the recordings generates code. You can see that code, and IMHO you should see how that stuff works. If you need a more versatile coded UI you can achieve that by modifying the generated code. In fact I STRONGLY recommend to split the generated classes and methods, and do some clanup.
The code generates a sort of UI Map (a class with properties referencing the UI objects used by the test). You can tailor that map manually adding or removing properties (after all, it’s just code) and create you own more complex UI map, in fact with effort, you can even make the maps “inherit” from other maps (more a la ASP.Net Master page).
In WPF you can check if a control exist or not, his UI style, it’s content and his children (if there are).
On the AutomationID subject, is only mandatory in the controls you need to check.
On the D&D… I have no idea. I never did UI tests for D&D.