Re: Principles for emulation for new features in WPT tests

On 07/03/2020 02:31, John Jansen wrote:
> Is there a set of principles around when/how WebDriver emulation should 
> be added for new features, especially those that are exposing new OS 
> and/or hardware capabilities?
> 
> At Microsoft, we’re starting the process[1] for contributing our dual 
> screen APIs to Chromium, but I don’t have a good sense of what is 
> typically expected of WPT tests for new features like this. I know we’ve 
> talked about this on different occasions, but I don’t think we’ve ever 
> written something into a spec or design document.

For wpt the rule is that we can only add testing features that have a 
spec. For cases where the platform feature is new I think it's totally 
reasonable for the testing spec to have the same maturity as the feature 
spec i.e. if you're writing tests for my-cool-feature and it defines a 
webdriver API it's fine to use that API in testing even if the spec is 
only a draft without clear cross-engine buy-in. Of course if the spec 
goes nowhere we'd probably end up removing the testing support in wpt as 
well.

In terms of the process for adding things to WebDriver, I think there's 
been a consistent position that those things should be added to the 
specs that introduce the related feature rather than WebDriver itself 
e.g. the permissions API and WebAuth both do this. There are some 
theoretical problems in avoiding name clashes but nothing that's more 
problematic than the rest of the platform. These extensions are supposed 
to get review from WebDriver experts to ensure they match the model for 
the rest of the feature.

Received on Sunday, 8 March 2020 09:47:17 UTC