Re: [permissions] Defining a testing API

That sounds like a good idea. For what it's worth, the Blink LayoutTests
are using a `setPermission()` which is mostly used as part of a helper
[1] for boring internal plumbing reasons. Eventually, `clear()` or
`clearAll()` methods could be added but so far they have not been
needed.

[1]
https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/http/tests/resources/permissions-helper.js

-- Mounir

On Wed, 3 May 2017, at 13:03, Mike Pennisi wrote:
> Hello all,
> 
> The Permissions specification operates on state that cannot be influenced
> in
> a way that is both standard and automated. This is largely by design.
> Permission fundamentally originates from the user, so allowing arbitrary
> code to control it doesn't make much sense.
> 
> ...in production settings. There is an important use case for controlling
> state programmatically: automated tests.
> 
> The ability to write automated tests for the Permissions API would allow
> shared test suites like Web Platform Tests [1] to promote consistency
> among
> browsers, and it would also allow application developers to more
> thoroughly
> test their own code.
> 
> The Permissions API isn't the only web standard that would benefit from
> dedicated testing support. All of the spec's "powerful features" are in a
> similar position. In all cases, programmatic control is undesirable for
> production settings but essential for conformance testing and application
> testing.
> 
> This is currently being discussed on the public-test-infra mailing list
> [2],
> specifically in the context of the developing Web Bluetooth API. In that
> thread, we're considering two very different approaches:
> 
> 1. Each standard defines a JavaScript API for testing with the
> understanding
>     that it is only to be enabled under highly-controlled circumstances
> 2. Each standard includes extensions to the WebDriver specification using
>     the mechanism it defines for this purpose [3]
> 
> Members of the Chromium team have prototyped a straw man implementation
> of
> the first approach for the Web Bluetooth API. I'm personally interested
> in
> exploring the second approach. I think that the relatively small internal
> state of the Permissions API make it a great candidate for
> experimentation
> along these lines.
> 
> Before getting started on a patch, I wanted to gauge interest from those
> involved with the specification. How do folks here feel about trying this
> out?
> 
> Mike Pennisi
> 
> Bocoup
> 
> [1] https://github.com/w3c/web-platform-tests
> [2] 
> https://lists.w3.org/Archives/Public/public-test-infra/2017AprJun/0018.html
> [3] https://w3c.github.io/webdriver/webdriver-spec.html#extensions
>

Received on Saturday, 6 May 2017 09:04:37 UTC