CODEWITHSUNDEEP
.netcoded-ui-testsgui-testingui-testing
Ben Aaronson
Ben Aaronson

Reputation: 6975

How does Coded UI's "always search" configuration work with parent/child objects?

As an example I'll use a very simple UI: A window (which I'll call W) with a single button (B). In Coded UI's UIMap, B is a child of W. i.e. in the XML specification of the map, B appears in W's "descendants".

Now say we have two instances of W open simultaneously. There is a search property which will distinguish W1 from W2 (for example, they have a different Name property), but there is no way to distinguish B1 from B2 except by their parent W.

I perform a test with the following procedure:

  1. Open the two instances of the window, W1 and W2
  2. Set the Name property on the UIMap's W UITestControl to match W1's name.
  3. Execute a Mouse.Click() on the UIMap's B UITestControl.
  4. Set the Name property on the UIMap's W UITestControl to match W2's name.
  5. Execute a Mouse.Click() on the UIMap's B UITestControl.

My understanding is that if neither W nor B have a "Search Always" configuration, then this will lead to B1 being clicked at both stages 3 and 5. So my question is what happens in the following scenarios:

Upvotes: 0

Views: 4104

Answers (1)

kida
kida

Reputation: 501

Without the Search Always configuration the engine will cache the ui element after finding it (by cache I mean keep a reference to the MSAA COM object that it got from that element). Having Always Search will, as it says, always do a search for the element as you said. Also the UITestControl.Find() does the exact same thing, so you can use that explicitly if you don't want to set the Always Search configuration.

When you change a control's search properties the engine will search for the element the next time you use that control (so after changing search properties the control will drop the reference to the ui element). However, if the child element (the button in your case) is already cached and you change its parent's search properties then you will have to call Find on the button (or set always search) or the engine will use the cached ui element.

If you want to use multiple UITestControls of the same class you should forget the UIMap and just create multiple instances of that class and then change their search properties separately. The UIMap is not responsible for the hierarchy of the elements it's just a way to access the elements.

So in your case:

var W1 = new MyWindowClass();
var W2 = new MyWindowClass();
W1.SearchProperties.Add( ... );
W2.SearchProperties.Add( ... );

Then if everything is set correctly W1->B will be the button in W1 window and W2->B will the button in W2 window.

If W is not a top level element then you can set a parent for it from the UIMap:

var W1 = new MyWindowClass(UIMap.UITopWindow);

These questions might also be of help to you:

Interacting with multiple instances of an application in Coded UI

SwitchTo method for Coded UI

Upvotes: 2

Related Questions