XPath alike mechanism to select UI objects in an application

[PiotrNestor]

For Web applications there is the XPath standard that uses path expressions to select nodes or node-sets in an XML document. This is a flexible and powerful mechanism to search for and select application elements.

It would be great to have a similar mechanism in TestStack/White for GUI applications. "UIItemPath" could have a similar syntax as XPath. This could be used for UIItem identification and in search criteria expressions. This would also provide a mechanism to define a search criteria for deeper and structured search expressions.

The present method in White for searching and selecting GUI objects is very cumbersome and code intensive. For complex GUI structures a lot of code is required to find and select an object.

Cheers
Piotr

[JakeGinnivan]

Could you give me an example of where it is cumbersome, and what the alternate XPath would look like.

The thing is that rich client has a FAR richer UI automation model than the web

[PiotrNestor]

I'm new to TestStack/White so my examples could be wrong. Also I'm using IronPython so the exaples are in Python syntax and not C# :)

Part of the GUI structure for the example application is (according to Inspect):
window -> window -> pane -> pane -> pane -> pane -> pane -> edit, edit, edit, edit, edit, edit

Some of the GUI objects have automationid, name, classname, etc. The interesting object attributes might be populated or just empty strings.

Lets say I want to access the third "edit" object. Actually I'm not sure what's the most simple way to do that in White.

Lets 'top' be the top window that I've got with 'GetWindow'
With search criteria that provides searching by UIItem path I could write (IronPython syntax):
e = top.Get(SearchCriteria.ByPath(".//edit"))[2]

The path ".//edit" :

• "." - indicates it's relative to the start/top object
• "//" - indicates anywhere in the structure below the start/top object
• "edit" - indicates the UIAutomation control type

Also 'Get()' returns an array (or list) of all found objects. The list is empty or populated with all found objects. '[2]' IronPython syntax provides the third element in the array/list if available.

The UIItemPath syntax (and functionality) follows the XPath syntax (and functionality)
Example:
/controltype[@Attribute='some text']

• controltype - UIAutomation control type, like window, pane, edit, etc.
• @Attribute - UI object attribute, like automationid, classname, name, etc.
• the attribute might have a value as astring

Basically the XPath is extended with support for UIAutomation control type elements.

I hope this explains the idea which is not new. You can check RanorexPath (I hope that the have not patended that :)

[PiotrNestor]

is there an email list or discussion group where TestStack/White questions/problems/ideas can be discussed?
Cheers
Piotr

---

Från: Jake Ginnivan [notifications@github.com]
Skickat: den 4 januari 2013 09:00
Till: TestStack/White
Kopia: Piotr Nestorow
Ämne: Re: [White] XPath alike mechanism to select UI objects in an application (#44)

Could you give me an example of where it is cumbersome, and what the alternate XPath would look like.

The thing is that rich client has a FAR richer UI automation model than the web

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/44#issuecomment-11874950.

[PiotrNestor]

Some of the "edit" control type attributes (according to Inspect):
ControlType: UIA_EditControlTypeId (0xC354)
LocalizedControlType: "edit"

The code for the above example using existing TestStack/White functionality could be:
e = top.Get(SearchCriteria.ByControlType(ControlType.Edit).AndIndex(2))
But this fails for some reason with: Exception: Failed to get ControlType=edit,Index=2

Also there is a problem with the above search criteria if there are more "edit" objects in different parts under the top window structure.

The above must be then split into:
p = top.Get(SearchCriteria.ByControlType(ControlType.Pane).AndByText("Login"))
e = p.Get(SearchCriteria.ByControlType(ControlType.Edit).AndIndex(2))

With search criteria path this could be more consistently coded as:
e = top.Get(".//pane[@name="Login"]/edit)[2]

[JakeGinnivan]

Using a tree search is really brittle, you then lock yourself into the physical layout of the UI, not the logical actions you are performing.

You should name, or assign automation Id's to all UI elements you want to automate, then you can simply just go Window.get("AutomationId").Click();

It will search the entire tree and get your control. You can get a sub control if you would like to gain a little performance.

[JakeGinnivan]

And will talk to the others about getting a discussion group setup. I think it would be good

[JakeGinnivan]

Could we move this discussion to https://groups.google.com/forum/#!forum/teststack_white

I would love to continue this in a better forum