1

Closed

Timing of Control "Instantiation"

description

I am working my way through automation using CodedUITest (and considering CUITe as an alternative).
The application I am working with is a WPF application.
My goal is to separate the details of the testing from the code.
I succeeded in creating a prototype (working off of spreadsheets) but I notice some 'weird' behavior while the automation activity commences.

One of the things I am baffled by is the timing of a control being instantiated, especially when the control is deep in the hierarchy of UI scaffolding, panels, tabs, etc.
From the code generated by the CodedUITest recorder it seems that until the particular control of interest is either being queried (Assert...) or activated (Click, etc.) there is only setting of the parent, search criteria, search configuration and window titles but no actual 'instantiation' of the control.
When is the control actually instantiated (beyond the new xxxx())?
Is it a mistake to issue a control.Find() on any of the intermediate objects in the hierarchy preceding the control?
Is it a 'waste' of an operation to do Find() followed by Click() or Assert?

As, in my paradigm, i issue a Find() on every control down the hierarchy, the strange behavior of the UI that I notice (scrolling down that i cannot account for, etc.) leads me to wonder whether this is due to using Find() on intermediate controls.

Much appreciated.
Closed Feb 5, 2013 at 1:33 AM by icnocop
Thank you. I'm glad you figured out the problem and grateful that you also posted the answer here! :)

comments

icnocop wrote Feb 2, 2013 at 4:16 PM

Hi Bey,

In the future, please use the discussions tab to ask questions.

The issue tracker should be used only to submit bugs and feature requests.

I'm not exactly sure, but it seems that your question is related to Coded UI Test and not the Coded UI Test enhanced Framework.

Questions for Coded UI Test should be asked in the "Test Tools in Visual Studio 2010 and 2012" MSDN forum.

If not, please provide example code to illustrate the issue you are having.

You can set breakpoints or output text for tracing to see when the code of interest is getting called while debugging.

Thank you.

BeyMelamed wrote Feb 4, 2013 at 11:19 PM

Thanks.

I will know better next time.

I figured out the answer to my question by trial and error.

The answer is:
There is no need to issue a Find() on each of the controls leadding to the one you are interested in. The control seems to become 'live' when you do something with it, click, assert, get property, etc.

Too bad Microsoft does not see fit to document this very complex paradigm (CodedUITest) to the level that would make it easier to make good use of it.