[sensors] Support scripting complex sets of mock sensor readings

Honry has just created a new issue for https://github.com/w3c/sensors:

== Support  scripting complex sets of mock sensor readings ==
This thread is separated from https://github.com/w3c/sensors/pull/369 (Introduce WebDriver Extension API) to discuss about supporting multiple HTTP requests for the use case of simulating a series of updating mock sensor readings. Thanks @jugglinmike for proposing a great idea!

Posted @jugglinmike's comments:
(https://github.com/w3c/sensors/pull/369#pullrequestreview-147716129)
>**Readings** Speaking as a web developer, think this API may not be powerful enough to thoroughly test my applications. Unless I am mistaken, the API requires a POST request for each new sensor reading I want to simulate. In many cases, I may not be able (or willing) to issue HTTP requests at an acceptable rate, especially if the remote end is running over the Internet (maybe via a third party like Sauce Labs).
>
>Instead of sending individual readings in a series, what if I could specify a JavaScript function capable of creating those readings? The implementation could call this at the device's sampling frequency, and if it provided a timestamp, I would be able to derive an expected value in a stateless way. Alternatively, we could accept an ES2015 generator function. A generator could yield readings and receive timestamps from the result (or I could maintain the timestamp myself using the performance timing API). In either case, we could use WebDriver's "execute script" command as a guide.

(https://github.com/w3c/sensors/pull/369#issuecomment-414760073)
>An application developer might write some code to respond to a rapid increase
in brightness. To test their application logic using this new WebDriver API,
they'd need to simulate the increase via a series of POST requests:
```
POST /session/c0ffee/sensor/ambient-light
{"illuminance": 0}
POST /session/c0ffee/sensor/ambient-light
{"illuminance": 0.2}
POST /session/c0ffee/sensor/ambient-light
{"illuminance": 0.4}
POST /session/c0ffee/sensor/ambient-light
{"illuminance": 0.6}
POST /session/c0ffee/sensor/ambient-light
{"illuminance": 0.8}
POST /session/c0ffee/sensor/ambient-light
{"illuminance": 1}
```
>However, they won't have any control over when those values get applied.
Depending on network effects, this could be not very rapid at all (and not very
smooth as a result). It will also get more cumbersome for more expressive
sensors (e.g. gyroscope) and for more complex readings (e.g. a "twist"
movement). And since all WebDriver commands execute in series, developers won't
be able to interact with the browser while this is happening.
>
>If instead, the automation API allowed developers to specify a function, they
could express an entire series of sensor readings that was arbitrarily complex
and continuous, and they could do it with a single POST request.
>
>Here's how it might look with a "classic" function body that received the time
offset as its first argument:
>
```
POST /session/c0ffee/sensor/ambient-light
{
  "body": "const t = arguments[0]; return {illuminance: Math.min(t / 1000, 1)};"
}
```
>And here's a fancier version using an ES2015 generator function that tracks the
time with its own internal state:
>
```
POST /session/c0ffee/sensor/ambient-light
{
  "body": "const start = performance.now(); while (true) { const t = performance.now() - start; yield {illuminance: Math.min(t / 1000, 1)}; }"
}
```
>The latter is more verbose for this example, but the ability to maintain state
could make it much easier to script complex sets of readings.

(https://github.com/w3c/sensors/pull/369#issuecomment-415147560)
>>How about keep single set of readings as current solution, and extend this
section by using WebDriver's "execute script" command to script complex sets
of readings?
>
>That could be a nice simplification, but I don't think the current text
supports it. There doesn't seem to be an JavaScript API to control this, so
the code that developers provide via "Execute Script" doesn't have an interface
to specify mock values.
>
>We could define such a JavaScript API, but that might not be necessary.
Developers may stub out the JavaScript constructor of the device they wish to
mock. Their stub constructor could generate instances which emitted events in
whatever sequence they liked. This just requires injecting code prior to the
evaluation of their application. For some configurations, that could be a
little cumbersome but not impossible. [I've filed an issue against WebDriver to
discuss making this easier](https://github.com/w3c/webdriver/issues/1293).
>
>If that is a tenable solution, then maybe web developers aren't an audience for
this feature, after all! What do you think?

Please view or discuss this issue at https://github.com/w3c/sensors/issues/371 using your GitHub account

Received on Thursday, 23 August 2018 07:05:05 UTC