W3C home > Mailing lists > Public > public-browser-tools-testing@w3.org > January to March 2014

Re: W3C Python WebDriver local end

From: Luke Inman-Semerau <luke.semerau@gmail.com>
Date: Fri, 7 Mar 2014 13:08:28 -0800
Message-ID: <CAL97Zu7t8KTfe+oJ6_ZUjkci5_7WWfG0Hrbv9oDQAa2VgJhU8g@mail.gmail.com>
To: public-browser-tools-testing <public-browser-tools-testing@w3.org>
Yes, to me it does. +1 for allowing a run-time defined strict or
compatibility mode (compatibility being the default for now)

On Fri, Mar 7, 2014 at 12:56 PM, Marc Fisher <fisherii@google.com> wrote:
> Hi all,
> So I am working on the new Python local-end for use in the W3C tests, and I
> have run into a general problem. There are places where the spec differs
> from the current implementations in significant and breaking ways, including
> the three following cases that will have wide-spread impact:
>   1. In
> https://dvcs.w3.org/hg/webdriver/raw-file/ac1cadc32661/webdriver-spec.html#json-encoding-of-commands
> the spec specifies that a command should contain a JSON payload with three
> fields, sessionId, name, and parameters, Selenium uses JSON payloads that
> just consist of the value of the parameters field (the other two fields in
> implicit in the end point of the command).
>   2. In
> https://dvcs.w3.org/hg/webdriver/raw-file/ac1cadc32661/webdriver-spec.html#status-codes
> the spec defines status codes as strings, but Selenium uses integers.
>   3. The spec doesn't seem to provide for cases where responses to commands
> don't include a JSON payload, but Selenium returns an empty body for some
> commands on success (such as get and quit).
> Ideally the Python local-end in use for the spec should conform exactly to
> the specified behavior, but this does make developing, debugging, and using
> it nearly impossible as there isn't currently a remote end that conforms to
> the spec. My current thinking is that I should allow it to work in to modes,
> 'strict' and 'compatibility'. 'strict' would conform as closely to the spec
> as possible, and would therefore be essentially unusable for the time being
> (presumably until Selenium 3 which I am assuming will conform to the spec),
> and 'compatibility' would allow for tests to be written against current
> WebDriver remote ends.
> Does this seem like a reasonable strategy?
> Marc
Received on Monday, 10 March 2014 10:23:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:49 UTC