question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[XCUITest] get missing white-box attributes for `getAttributes()` API.

See original GitHub issue

Unfortunately, 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:closed
  • Created a year ago
  • Reactions:1
  • Comments:7 (7 by maintainers)

github_iconTop GitHub Comments

1reaction
LeoNatancommented, Jun 26, 2022

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, but element.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 even scroll() action there. 🤣

1reaction
LeoNatancommented, Jun 23, 2022

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

No results found

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found