W3C home > Mailing lists > Public > www-archive@w3.org > July 2017

Structuring WebDriver callback code

From: Geoffrey Sneddon <me@gsnedders.com>
Date: Thu, 20 Jul 2017 11:09:34 +0100
Message-ID: <CAHKdfMj=nnoeTtaO7hZaV6PUKQRqXhRHcrwOuuUfZwjDVg-m2A@mail.gmail.com>
To: James Graham <james@hoppipolla.co.uk>
Cc: www-archive <www-archive@w3.org>, Patrick Kettner <patket@microsoft.com>
As I've mentioned before, my first attempt at this is an ugly mess that
really doesn't seem sane. Before I try and rewrite this again, here's an
outline of what I think is sensible:

   - Have an HTTP server started from within TestEnvironment, listening on
   the subdomain webdriver (of the configured domain in config.json), and
   probably using BaseHTTPServer directly (v. WptHttpdServer or whatever it's
   called, with all its extra features we don't need or want here),
   necessarily in a new process/thread.
   - Modify the executeAsyncScript callbacks to pass an argument (done:
   bool), which is false when a WebDriver request has been sent and true when
   we've completed the test. (Note this gets complicated in the testharness.js
   case as the current script add an event listener that calls the callback;
   potentially this could fail if we return the callback, start running
   WebDriver commands, the script returns the message, and then we run
   executeAsyncScript to readd the listener—we need a decent solution to avoid
   flakiness there, I think).
   - Have a callback API (with a Server.add_callback or similar), which the
   test runner hooks into to add a means to send the WebDriver commands to the
   browser based on the HTTP requests.

This still seems kinda messy, but I can't think of any obvious improvement
on it. Suggestions?

/g
Received on Thursday, 20 July 2017 10:09:57 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 20 July 2017 10:09:58 UTC