Automating WPF (.NET)

Hi Aneez,



In general, automation of WPF applications is not harder that automation of Windows native applications. Even more - as .Net applications are open for TestComplete, you can always access applications UI controls via their native methods even if the given control is not explicitly supported by TestComplete.

What makes automation of WPF applications harder, is that WPF graphics system places a huge amount of intermediate controls between, for example, the form and a text box on it. Though TestComplete has means to hide the unnecessary controls to ease the GUI hierarchy.

Developers can easily make things easier or harder for you, as a test automation, depending on the approach they use during development, but this is applicable to any application and is not WPF-specific.

Hi Alexei,



Thanks for your response.



The aspect of that WPF and it's graphcis system and their amount of controls makes it harder makes sense.



Could you please elaborate on Developers can make test automation easier or harder for you?



Maybe to help answer the above, we use Agile Test Driven Development - I am not sure what suggestions you may have that I could relay to developers to make the process of test automation with WPF easeir for testing purposes.



I do appreciate your responses and help to date thus far.





With Kind Regards,

Aneez.

Hi Aneez,



> Could you please elaborate on Developers can make test automation easier or harder for you?

According to my experience, the best thing developers can do is to assign unique external identifiers (name, id, ControlID, etc. depending on the application type and development tool) to all controls used by the user and/or used for verification. This will make it possible for you to easily and reliably identify and operate such controls in your scripts and ease internal scripts' logic.

Unfortunately, in a lot of case and/or used development methodologies/patterns, developers are either not interested in unique and stable controls naming or such naming is explicitly not recommended by the used pattern. While this might have sense for development, this usually greatly complicates tester's life as in this case you must find the ways how to distinguish, for example, between two grids that are seen in TestComplete's Object Browser as WPFObject("WPFGrid", "", 1) and WPFObject("WPFGrid", "", 2) when both of them are on the same level of hierarchy in Object Browser and when the index value (the value of the third parameter) can change depending on the order these grids were opened on screen by the user. The need to solve this adds complexity to your test code, slows down the actual tests development, usually slows down tests execution speed and increases the chances of test false negatives (or false positives) because of incorrect controls identification.