W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2018

Re: WPT test dependencies

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 31 Jan 2018 14:47:55 +0100
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, public-webrtc@w3.org
Message-ID: <7aec2e02-af8a-ec35-98b0-bdc25896071c@alvestrand.no>
Den 31. jan. 2018 09:27, skrev Sergio Garcia Murillo:
> When I first read the mail, I was quite in agreement with Philipp, but
> the more I think about it, the less I am.. :)
> 
> Regarding reducing dependencies with other parts of the spec, i think it
> is a good goal, and we should do it if the alternative provides the same
> validity of the result. If the alternative is parsing the SDP or not
> testing it, then I would strongly oppose to that.
> 
> I agree that most of the test in WPT test the js api layer, like
> validating that if I set a value, then I get the same value back, and
> not the effect of that setting, but in order to test that part we would
> need some kind of external server that test IETF stuff compliance. I
> found that piece missing and really important (for testing simulcast for
> example), although I am not sure if that testing should be in the scope
> of the WPT or on something different (KITE?).


It is certainly in-scope for KITE. (That's my generic answer when the
question involves interoperability or Net-facing behavior).

> 
> Regarding changing new RTCPeerConnection() by new
> RTCPeerConnection(null) just because some browser does "a silly thing"
> and is not spec compliant, well.. We should not hack the test so a
> certain browser can pass it, but viceversa.
> 
> One last comment, I think we should be more careful when making changes
> to the spec that potentially breaks WPTs and if not providing a change
> to the WPT itself, at least open an issue so we can track those changes.

Our theoretical policy (after the last TPAC) is that a spec change
request needs to have a test change request along with it.
So far, we've not been very good about policing that.
Received on Wednesday, 31 January 2018 13:48:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 31 January 2018 13:48:23 UTC