testID information not visible on UIAutomator in Appium.

[kahn004]

Hi there,

We are doing an automation test for Android (API version 21) on Appium.

And we are using UI Automator Viewer to see the node details information and we need resource-id information visible in order to test for unique nodes so we know which elements are being interacted.

But currently, resource-id column is empty even though we have applied testId property on each <View>.

Please close this issue if there is a duplicate, otherwise please advise on what we can do to have each nodes to have unique id's specified from testId value provided.

Thanks,

Sam

[ashleydw]

I too struggled with this and actually gave up on android testing with appium.

Appium is in the process of upgrading to uiautomator v2 which can find by tags because we have the full instrumentation API available. It'll probably take a very long time to be ready though. In uiautomator v1 (what appium currently uses), this isn't possible.

The only work around I know of is exactly what you mentioned, strip the automaton only content descriptions out of production builds.

See https://discuss.appium.io/t/react-native-ui-element-access-via-testid

[atom992]

we need resource-id information visible in order to test too.

[kahn004]

Workaround:
Use both accessible and accessibleLabel on your views (so far, seems to work on View, Text, TextInput) and UiAutomator will generate content-desc field from accessibleLabel.

For now, we can use content-desc to identify tags.

DOC on accessiblity label:
https://facebook.github.io/react-native/docs/accessibility.html#accessibilitylabel-ios-android

Ideally, we should be able to test id's only with testId. But for now, it is what it is :(

[JumalDB]

We need resource-id information visible for testing too. Is there any date when it will be implemented?

[talarari]

Any update on this?

[sijicl]

Ping..Bothered by this issue as well. How does React Native community do end to end UI test on Android App without resource id supported here? Thanks.

[sondremare]

upvote

[tuckerconnelly]

Here's where the testID is set on android views:

react-native/ReactAndroid/src/main/java/com/facebook/react/uimanager/BaseViewManager.java

Line 88 in 3d3b067

view.setTag(testId);

Not the best with Android, but seems like you'd want to use setId() there instead of setTag(). That way, if you were using webdriverio, you could do something like:

var selector = 'new UiSelector().resourceId("whatever")';
browser.click('android=' + selector);

...I think?

I can get around to submitting a PR for this when I get to android automation.

Edit:

Alright, getting more familiar with Appium. Looks like in the BaseViewManager we'd want to use .setContentDescription(), and then you could access it on webdriverio like this:

client.element('~myTestID')

[tuckerconnelly]

@lexs Is there anything depending on the testID being in the tag? Would you accept a PR for this?

[mkonicek]

Commented on #8843, copying here:

We use the tag in our internal e2e testing system. contentDescription is used for accessibility: https://developer.android.com/training/accessibility/accessible-app.html

You could:

• Look up views by tag in Appium
• Use accessibilityLabel if you must use contentDescription: https://facebook.github.io/react-native/docs/accessibility.html

[jasonfma]

Is it actually bad to set the resource-id as well as the tag? I would rather use resource-id than override the content description since it is used for accessibility. But of course tag does seem like the better option all around.

@mkonicek do you have an example of how to get the view by the tag in appium? I think we're all here because we're not sure how to do it. Thanks :)

[talarari]

@jasonfma its not currently supported in appium
appium/appium#6025
Im using content description, how are you using resource id?

[talarari]

any chance of setting resource-id in addition to content-desc?

would allow us to select the element in appium today, until they add support for selecting an element by view tag.

the current solution is kind of bad for accessibility because it forces us to set accessibility labels for controls that are not important for accessibility.