search

theintern / leadfoot

A JavaScript client library that brings cross-platform consistency to the Selenium WebDriver API.
Other
170 stars 24 forks source link

testing against Appium? #21

Closed jlipps closed 8 years ago

jlipps commented 10 years ago

I saw you're currently testing against (what I presume to be mobile safari on) ios-driver. Any interest in supporting Appium as well?

csnover commented 10 years ago

I’ve been told that recent versions of Appium are working. There were some blocking issues that prevented it from working at the time the library was written, which is why it isn’t on the list of known supported servers. If you run the Leadfoot test suite against Appium and are able to introduce feature detects/fixes that bring it up to passing, I’d be glad to add it to the list of officially supported Selenium servers.

jlipps commented 10 years ago

ok, sounds good

tylersnavely-wf commented 10 years ago

This does work on Appium to a degree. The Leadfoot API doesn't seem to have support for the Appium version 1.0.0+ touch action gestures. https://github.com/appium/appium/blob/master/lib/server/routing.js#L86

Using the gesture APIs from Leadfoot result in "Not yet implemented" errors from Appium version 1.2.4

csnover commented 10 years ago

@tylersnavely-wf Leadfoot implements the endpoints defined in the JsonWireProtocol spec. While the touch API in JsonWireProtocol is underspecified and pretty terrible, it is at least in a spec. The endpoints you’re referencing aren’t part of any spec I am aware of; at least, they’re not in JsonWireProtocol or the W3C editor’s draft—and technically violate the W3C spec as a result. Unless they get a written specification somewhere/adopted by the W3C draft/etc. I’m wary of implementing them and having things break badly later. I would need convincing that this isn’t short-term gain for long-term pain. (For instance, Appium created a redundant “contexts” API, even though the window endpoints already exist and are used by everyone else for the same purpose—that kind of redundancy is bad for the API.)

jlipps commented 10 years ago

Hi people.

The multiaction API is specified here: https://dvcs.w3.org/hg/webdriver/raw-file/default/webdriver-spec.html#multiactions-1

I don't believe this document specifies the structure of the endpoints themselves; I can't remember where we found the motivation for ours but I don't believe it was just random. I'm guessing we got it from Mozilla who pioneered the API.

For instance, Appium created a redundant “contexts” API, even though the window endpoints already exist and are used by everyone else for the same purpose—that kind of redundancy is bad for the API

Unfortunately window_handles doesn't cut it for changing contexts. As you can see in the mobile JSONWP spec draft, which I authored in conjunction with the selenium project leaders, we've all settled on a context API.

It's true it's not part of the w3c spec, but it's intentionally being left out so as not to add complication to getting that through the draft stages. As far as the future of the JSONWP is concerned, the mobile spec draft is the reference.

csnover commented 10 years ago

Unfortunately window_handles doesn't cut it for changing contexts.

Why?

simonhowlett-wf commented 10 years ago

Any further thought on this? it would be good to see Appium gesture support in leadfoot

csnover commented 10 years ago

Actions seem to be so significantly in flux in the spec that I don’t think we can safely implement them at this time. For instance the link for the multi-action API isn’t valid any more since that part of the spec appears to have been rewritten.

I’m also still waiting for an answer to my question. :)

csnover commented 10 years ago

None of what I said in the previous comment should be taken to imply that nobody should do work on providing a preliminary implementation (in other words: patchwelcome), but anything like that would need to be hidden behind flags until the spec is at least semi-stable, and nobody on the SitePen side is currently planning on doing this work.

jlipps commented 10 years ago

Why?

From the perspective of leadfoot, what does it matter why, since all the projects have agreed on it? But the main reason is that you might have multiple windows within a context. You could imagine a browser application, for example, having a couple webviews, each with a set of window handles. They might exist in overlapping namespaces. What is the 'default' window? Is it the default webview window or the native context of the app? It felt clearer to all of us in the spec meeting to create an orthogonal category for this. If you feel strongly that it's a bad idea from a spec perspective, please write in to mobile-jsonwp-spec@googlegroups.com and share your thoughts. The spec is not in stone yet.

csnover commented 9 years ago

From the perspective of leadfoot, what does it matter why, since all the projects have agreed on it?

That’s a pretty exclusionary outlook. Who is “all the projects”? I was never invited to any spec meeting so this is not a project that has agreed. There’s also no way I could understand the rationale behind such a decision, or which (if any) alternatives were discussed, since there are no minutes from these meetings published anywhere that I can find.

I asked because as far as I can tell both ios-driver and selendroid successfully implemented webview/browser view switching using only the window context API and it worked fine. IIRC there’s a WEBVIEW_n for each WebView window and other entries for native views. From all I could tell the original mobile spec duplicated other already existing APIs and this just seemed like yet another duplicate API.

You could imagine a browser application, for example, having a couple webviews, each with a set of window handles. They might exist in overlapping namespaces. What is the 'default' window? Is it the default webview window or the native context of the app?

I’m not super clear on how a separate context API solves this. Why not just allow end-users to define what the default window for their mobile application is through the capabilities object? Then no new APIs need to be written and no changes need to be made to WebDriver clients to support mobile apps.

If you feel strongly that it's a bad idea from a spec perspective, please write in to mobile-jsonwp-spec@googlegroups.com and share your thoughts. The spec is not in stone yet.

If this is for the WebDriver spec is there not an open ticket at https://www.w3.org/Bugs/Public/ that I could write to instead? I don’t see any tickets about adding any new mobile context API. I would prefer to avoid having 5 different places to discuss things (like I would prefer not to have multiple APIs to do the same things :))