Xcode UI Tests can't find views that are added programmatically

Question

I'm adding a child view to my view programmatically, and when I do I attach all accessibility params to it:

  [labelView setAccessibilityLabel:@"label"];
  [labelView setIsAccessibilityElement:YES];
  [labelView setUserInteractionEnabled:YES];

But when I query the UI like this:

 let app = XCUIApplication()
 app.staticTexts["label"]

The test fails because it couldn't find the view.

How do I deal with this, how to make dynamically added views available for UI Testing?

Armistice

What exactly are you trying to test? Just that a view has loaded, or are you trying to look for objects within the view? – Vernacularism

Who is the parent of labelView? – Rhoads

I'm trying to read the label's content (.value). @TomasCamin its a UIEditText but what difference does it make ? – Armistice

Answer 1

You need to make sure that the container view of your label view (UIEditText?) doesn't have isAccessibilityElement set to YES. If it does it will hide the accessibility of its subviews (your label).

Check Make the Contents of Custom Container Views Accessible in the Accessibility Programming Guide

Rhoads

Thanks for the answers, while this is an understandable requirement for Accessibility design, its an obvious shortcoming in Xcode UI Testing. – Armistice

It took me a while to figure it out myself, but in the end it kinda makes sense. Anyhow the docs are worth a read. – Rhoads

Answer 2

I had a different solution because I caused myself a different problem that manifested in the same way, namely XCUITests couldn't find basic elements. My app uses a UIWindow with UIWindow.windowLevel set to .normal + 2 to display a fullscreen loading spinner on top of the other windows. It turns out even when this window is not in the view hierarchy, or the accessibility hierarchy, or the responder chain, merely by its existence, it breaks the accessibility/view-hierarchy crawling system that UI tests use.

To verify this, I removed extra UIWindow instances entirely from the app. The fix ended up being simpler, just using windowLevel = .alert and not adding constants to UIKit's constants.

Corporal