[e2e-testing][Appium] Adding support for android:id

[jsdevel]

• Calling view.setId() with the matching resource-id of an id found in R.class when BaseViewManager.setTestId is called.
• Adding TestIdUtil in common to store mappings for testID with attributed views and their original react tag value.
• Changing the signature for Event Classes to require the View instead of the viewTag. This reduces the number of locations where TestIdUtil.getOriginalReactTag is called.
• Overriding BaseViewManager.onDropViewInstance to perform TestIdUtil mapping cleanup.
• This closesAdd support for resource-id #9777.
• In order for this to work properly, an id resource needs to be manually added to android/app/src/main/res/values/ids.xml. Here's the contents of that file:

<?xml version="1.0" encoding="utf-8"?>
<resources>
<itemname="something"type="id"/>
</resources>

[ghost]

By analyzing the blame information on this pull request, we identified @kmagiera and @sebmarkbage to be potential reviewers.

[jsdevel]

@ide what's the best way I could test this change?

[ide]

Building from source and running the UIExplorer + temporarily modifying its code to invoke your new code is a reasonable path forward.

[jsdevel]

Thanks @ide !

I've verified locally that it works!

[jsdevel]

I've also verified that non-existent ids in ids.xml don't have any side effects i.e. testID="some-id-not-in-ids.xml" doesn't break anything.

[jsdevel]

cc @mkonicek@bestander

[jsdevel]

Looks like the tests for HMR are failing on most PRs.

[bestander]

Yeah, trunk was broken over weekend.
Should be fixed now

[aaronechiu]

isn't this and line 94 checking the same thing? can you combine this logic?

[jsdevel]

view.getResources().getIdentifier(testId, "id", view.getContext().getPackageName()) will return 0 if no matching identifier is found. I wanted to avoid calling it more than once for a given testID if possible which is why there are 2 checks:

• The first check is for caching purposes.
• The second check is to avoid setting the testId on the View if the user didn't define it.

[aaronechiu]

I'm pretty wary of setting the ids on views because we at least use the ids of the ReactRootViews to track the ReactRootViews so this can break something in a hard to track way...
I can't remember off the top of my head if we use the ids of non-ReactRootViews else where though...

[jsdevel]

I'm pretty wary of setting the ids on views because we at least use the ids of the ReactRootViews to track the ReactRootViews so this can break something in a hard to track way...

• Is there an example of where a ReactRootView would ever have a testID? I'd like to test that in JSX if possible.
• I could add a check and only set the id if view.getId() == 0.

[jsdevel]

@AaaChiuuu I added an additional check to avoid setting the id on the View if it currently has an Id.

[jonestheguitar]

elementById works the same way.
Yes waitForElementByAccessibilityId might be slightly faster - but it wouldn't work on iOS and I don't really want to make my tests platform-specific.

[jsdevel]

I see. That's pretty cool in the sense that it works. I'd say your workaround is probably the best approach that we have at the moment. It would be much easier if testID was all that was needed though. Per the documentation, accessibilityLabel affects the behavior of the view when present, so it's possible the app works during testing when the workaround adds the label, but it doesn't work in production when the label is not present.

[jonestheguitar]

@jsdevel Good that you now understand it but painful that I had to spend so much time convincing you. I suggest next time you keep more of an open mind - you could easily have spent a few minutes trying the workaround for yourself rather than repeatedly shooting it down with unhelpful comments like "There's no way that works" just because you didn't understand it.
Agree on the need to get testID working properly though. If I understand correctly uiautomator 2 has view tag support so to me the best solution would be for Appium to add that as a locator strategy in waitForElementById etc.

[jsdevel]

painful that I had to spend so much time convincing you

@jonesdar It's quite possible that others will have similar questions. I wasn't trying to be difficult. Sorry if my questions caused you some consternation. You helped me to understand something about appium that I haven't seen documented anywhere and for that I am grateful.

If I understand correctly uiautomator 2 has view tag support so to me the best solution would be for Appium to add that as a locator strategy in waitForElementById etc.

In case any testing library authors are reading this, the method is findViewWithTag.

[skovhus]

@mkonicek is this still down prioritized?

[curioustechizen]

@jonesdar Thanks for this work-around! Just to point out, I had to use the plural forms of the locator methods for Appium to be able to find my view with the accessibilityLabel on Android: i.e., waitForElementsById instead of waitForElementById and elementsById instead of elementById.

Using the plural form is apparently what tells Appium to try multiple strategies. The clue was in the Appium server debug logs. When I used the singular form, the log had the equivalent of

[debug] [AndroidBootstrap] Sending command to android: {"cmd":"action","action":"find","params":{"strategy":"id","selector":"Email","context":"","multiple":false}}

The "multiple":false prompted me to explore this a bit and I finally found the answer here

[voidgit]

@mkonicek Are there any plans to proceed with this issue?
Because tag is not available via Appium on Android (and will be not available in foreseeable futurte) due to UIAutomator2 limitations (appium/appium#6025 (comment))
and only AccessibilityLabel is left and given this is not an id and we are going to use AccessibilityLabel for, actually, accessibility there is no viable way to test react-native applications on Android.

[marlenabowen]

@mkonicek any ETA for when FB might open-source the internal e2e framework?

[kholiavko-roman]

Can I now to set resource-id for android from react-native ?
I need it for running pre-launch tests on Goolge Play.

[ThaJay]

I'm afraid not. This should have been handled / merged months ago.

[mkonicek]

Hey everyone, so sorry about the long radio silence about this. I left fb in the meantime and went traveling for 4 months and then joined a startup where I'm doing some native Android dev for now, currently playing with integrating React Native to an existing native app.

I feel very sorry about closing this PR and seeing it disappointed so many people. I thought someone from the community would provide a way to look up elements by Android view tags like we did at fb and the issue would be solved. It looks like it's harder to add support to Appium than I thought, but will happen eventually (see appium-espresso-driver, found via a comment on the Appium issue).

At the same time, I'm glad there is the workaround by @jonesdar (#9942 (comment)). To me it looks like a reasonable workaround and I'd use it when testing my app with Appium. I'll copy it here to make it easier to discover (at the end of the comments section). Quoting @jonesdar:

I defined a testProps(id) function which returns an object {testID: id, accessibilityLabel: id}.
It's used in all our RN views e.g.
<View {...testProps('idForThisView')}>

Appium can then find elements by id on both iOS and Android. Yes, the accessibilityLabel is user-visible but testProps is conditional on build type so we only include these props for a test build anyway.
It means we're not quite testing with the exact build we ship, but it's worked well for the last 9-10 months.

[jonestheguitar]

Worth pointing out that the workaround needs a few tweaks on newer versions of Android.
Firstly you'll need to specify automationName: 'uiautomator2' in Appium's desired capabilities (I think the default 'uiautomator' has been deprecated from Android 5.0 onwards).

Then you'll notice that waitForElementById, elementById etc. no longer do multiple locator strategy fallbacks (so elementById won't fall back to elementByAcessibilityId etc.) - I fixed that as follows:

 if ('android' === process.env.APPIUM_PLATFORM) {
// uiautomator2 doesn't seem to do multiple locator strategy fallbacks
// so map id to accessibility id directly
wd.addPromiseChainMethod('waitForElementById', id => {
return this._driver.waitForElementByAccessibilityId(id);
});
wd.addPromiseChainMethod('elementById', id => {
return this._driver.elementByAccessibilityId(id);
});
wd.addPromiseChainMethod('elementByIdOrNull', id => {
return this._driver.elementByAccessibilityIdOrNull(id);
});
wd.addElementPromiseChainMethod('elementById', function() {
return this.elementByAccessibilityId(id);
});
}

i.e. centrally map waitForElementById() to waitForElementByAccessibilityId() etc. - to ensure that Appium finds the testIDs we've put into the accessibilityLabels.
Note that you could just use the accessibility id methods on Android and the id methods on iOS but I've always used the same test code on both platforms and I don't want it to diverge now.

I think I read somewhere that you can do multiple locator strategy fallbacks by using plurals (waitForElementsById, elementsById etc.) but I haven't tried that - and it would still require a global find/replace in all test code (or a central mapping as above) anyway to get existing tests working again.

On the plus side, uiautomator2 seems to run my tests twice as fast as uiautomator.

[jsdevel]

I'd happily get this working again 😄 any takers from the RN team?

[jribeiro]

I've written a babel plugin to address this issue in the meantime. The idea is to add a property accessibilityLabel every time a testIdjsx property is found. Essentially it'll allow you to provide meaningful accesibilityLabels in your application and on an Android specific build replace this by the defined testIDs.
https://github.com/jribeiro/babel-plugin-jsx-property-alias

Hope it helps

[lightboys22]

I realize that my pull request is very similar to this pull request.

[jsdevel]

@lightboys22 I'm sorry that you went down this road. I feel your pain 😢

[Mishan999]

Good

[tylermurry]

We use Appium to test our applications and I was able to solve this problem very elegantly with react-native-testid.

[lightboys22]

@tylermurry react-native-testid will change the accessibilityLabel on Android platform. Our accessibilityLabels won't be unique.

[Frank1234]

A copy and paste solution using Espresso and the solution from #9942 in this article:

Espresso testing React Native

[jdeff]

I know this ticket is old and many people have found suitable workarounds, but in case anyone still cares (and is actually using accessibilityLabel for accessibility like one should 😉), I've put up a super simple PR that should fix this. cc @jsdevel@lightboys22

[sasmit]

@jdeff
I am on react-native 0.62. So I took your changes(commit #29610)) locally to node_modules (path:ReactAndroid/src/main/java/com/facebook/react/uimanager/ReactAccessibilityDelegate.java ) and tried to test my application with UI Automator view and unable to get the vlaues for resource-id. Its always empty.

Am I missing something here ?

[thanveershah]

Same, resource-id is still empty, any solution yet for this?