How can I see the XCUIElement tree?

Question

Background

I'm experimenting with UI testing in Xcode.

Question

Is there a command in Xcode that will allow me to see a 'tree' of accessible elements and their relationships? Something similar to the 'page' command in Appium?

Ideally I want to run a command in the debugger that gives me a list of elements available for selection/manipulation. I know I can call debugDescription on a single XCUIElement but that only gives me info for that element.

Konstantin

Did you find a way to get this information? – Normalie

Unfortunately it doesn't seem like something apple is planning on providing. The answer below is probably the best way to go about it but it's not ideal. – Konstantin

Answer 1

Set a debug breakpoint where you would like to see the view hierarchy tree and then run the following command in Console:

po print(XCUIApplication().debugDescription)

That prints out everything XCUITesting has access to. You can also just throw that in to your test:

func testTreeExample() {
    XCUIApplication().buttons["login"].tap()
    print(XCUIApplication().debugDescription)
    XCUIApplication().buttons["next"].tap()
    print(XCUIApplication().debugDescription)
}

That way if you are having trouble finding something you can have it automatically print out what the app sees right after you do something.

Gratt

The problem with debugDescription is that it does't format the output properly and is very hard to read.po XCUIApplication() will print the hierarchy out in a nice tree format – Axe

@kakubei: You're right when you say that the XCUIApplication.debugDescription String output is hard to read. (It shows the line breaks as \n rather than as line breaks.) Calling po XCUIApplication(), as you have suggested, is shorter (and better imo) than the command in this answer but it is actually functionally equivalent given that the command in this answer feeds the XCUIApplication().debugDescription String output to the print function and then feeds the output of that to the po command. – Overdose

Answer 2

This isn't exactly what you're asking for, but Xcode’s Accessibility Inspector makes it much easier to look at your view hierarchy in terms of what elements are accessible via Identifiers. (N.B. It's not the "Label" in IB's Accessibility panel that matters, it's the "Identifier" field.):

In Xcode 7.2, open Xcode->Open Developer Tool->Accessibility Inspector. (You may need to give the app permission to run in System Preferences.) Then launch your iOS app from Xcode and hover over any UI element in the SIMULATOR. You’ll see comprehensive information about the element type, description, hierarchy, etc.

Anytime you record UI actions and the output doesn't look right, use the tool to figure out what accessibility descriptions need to be added, changed, or removed. (I spent a couple days trying to get a deeply embedded UISegmentedControl to change via the UI Test harness, and the problem became obvious once I figured out how to use the Accessibility Inspector tool.)

Thanks to the folks at shinobicontrols.com for the great tip!

Nesselrode

I'm not fully on board with ease of use of Accessibility Inspector. I've found it to be very flakey and it provides incomplete information. – Standice

Answer 3

I would suggest choosing from the menu bar: Debug > View Debugging > Capture View Hierarchy when running in debug. Not only do you a way of visually representing the views but also the left-side debug navigator shows the hierarchy. This may not be one-for-one with UI Testing's perspective but it can be very helpful. Hope that helps.

Pontificals

That's really cool, but it doesn't answer in terms of accessibility... It would be nice if apple gave us a convenience method to get a list of available elements with identifiers. – Konstantin

When you select a view in Xcode's view debugger, the object inspector on the right shows accessibility information. That might be useful. – Baptiste

Answer 4

Put a breakpoint in any of your tests and then enter po XCUIApplication() in the Console. That will print out the whole app's accessibility hierarchy in an easy-to-read tree format.

Axe

Answer 5

The way Appium does this is using Facebook WebdriverAgent. As far as I can tell, the way they do it, essentially, is starting from the root application element and collecting information about each child, then recursing.

Contraception

mind answering this question if you know the answer? #58391893 – Makell

Answer 6

What about http://fbidb.io?

With idb ui describe-all command you get the accessibility information of all the elements on screen (not the entire app) https://fbidb.io/docs/commands#accessibility-info

Bedspring