[XCUITest] get missing white-box attributes for `getAttributes()` API.
See original GitHub issueUnfortunately, XCUIElement can give us limited list of attributes we currently return from getAttributes()
API (on the current implementation of Detox-iOS).
The solution for that, will be to get the missing attributes (in which we can’t get on the black-box side of the new iOS implementation, the XCUITest target) from the white-box side (using the Detox framework in which we inject to the application). After that, the returned attributes will be a combination of “black-box” attributes (in which the XCUITest target has access to) and “white-box” attributes.
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:7 (7 by maintainers)
Top Results From Across the Web
No results found
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
The issue with passing more info is that information passes through XPC, which is very tight and would be a tall order to hack that (you don’t have access to the accessibility daemon process).
It goes xcuiquery -> xpc -> accessbility daemon -> xpc -> app process -> iterate elements -> xpc -> accessbility daemon -> xctest. I couldn’t find any effective way to attach additional data in that chain in a meaningful way, unless some of the known fields are modified. But I never really tested how feasible that is (for example, who else relies on these identifiers in the system—app or test or accessibility—which may fail due to swizzled identifier, for example.
My eventual plan was to have two distinct matcher/action systems and let the user pick from a custom—but limited—as the default, or the XCUI—for wider access in system processes and web—but with many known limitations.
Something like
element(by.id('app_login')).tap();
would use the default system, which is the custom matching and actions, butelement.with_xcui(by.id('app_login')).tap();
would instead use the XCUI query system. XCUI is very limited and cannot be really relied on, especially for React Native. There isn’t evenscroll()
action there. 🤣Hello
Be careful because there is no uniqueness guarantees for identifiers. I found a way in the past to come between the accessibility query system. You can put a breakpoint in the
accessibilityIdentifier
getter to see how the system queries. You can swizzle there.