feat(iOS): support interactions with secured web-view elements. #4505
Conversation
asafkorem
force-pushed
the
feat/secured-webview-testing
branch
from
ba9145c
to
5773022
Compare
asafkorem
force-pushed
the
feat/secured-webview-testing
branch
from
c8589d8
to
539bc3d
Compare
asafkorem
changed the title
| @@ -1112,6 +1112,31 @@ declare global { | |||
| * web.element(by.web.tag('mark')) | |||
| */ | |||
| tag(tagName: string): WebMatcher; | |||
|
|
|||
There was a problem hiding this comment.
I know this is an old discussion, but can't we actually afford to mix web elements and native matchers? This would be more reasonable than to say web.label (which would obviously refer to aria-label rather than XCUITest's own understanding of what label is).
There was a problem hiding this comment.
Totally a reasonable idea. We already use the same names in most places, and semantically it's already under the web.element context, so it shouldn't add any confusion. Let's follow up on that. We might want to break it in Detox 21 or deprecate it sooner..
| * @example | ||
| * web.element(by.web.value('hello')) | ||
| */ | ||
| value(value: string): WebMatcher; |
There was a problem hiding this comment.
Sounds like <input value="..."> right? Why is it iOS-only, then? 🤔
There was a problem hiding this comment.
We should have it for Android as well. As soon as we rewrite the infra to use same JS code builder for Android + iOS, we'll have this API there as well. Right now, we just wrap Espresso on Android, and it doesn't have it
There was a problem hiding this comment.
actually, we don't have to wait and we can simply wrap runscript from the javascript side for Android and support it there as well, however there are many other things that can be done like this, and I prefer to keep it and do it properly for all
| * @example | ||
| * web(by.web.type('textField')).asSecured() | ||
| */ | ||
| type(type: string): SecuredWebMatcher; |
There was a problem hiding this comment.
How do you plan to solve issue that iOS and Android types are likely to be very different?
device.getPlatform() === 'ios' ? ... or ... how?
There was a problem hiding this comment.
This uses the accessibility types from the iOS system level (see XCUITest, Accessibility Inspector). I believe the best approach will be to understand what heuristics we can use for Android accessibility types to classify different elements and come up with new shared types. At the moment, I prefer to simply expose the iOS types to avoid premature optimization. This is an experimental API, so once we have a good candidate to replace it, we'll do it.
asafkorem
force-pushed
the
feat/secured-webview-testing
branch
from
5e5b66b
to
4159f2a
Compare
asafkorem
force-pushed
the
feat/secured-webview-testing
branch
2 times, most recently
from
f9b5830
to
ebc6400
Compare
asafkorem
force-pushed
the
feat/secured-webview-testing
branch
from
ebc6400
to
6df8eeb
Compare
No description provided.