- From: Steve Block <steveblock@google.com>
- Date: Mon, 7 Feb 2011 11:56:26 -0800
- To: Lars Erik Bolstad <lbolstad@opera.com>
- Cc: "public-geolocation@w3.org" <public-geolocation@w3.org>
> If there is general agreement about this I propose that we remove those test > cases from our test suite that report a pass or fail based on checking > against an expected numerical parameter value. I think that all tests that use setupDevice() to supply the output of the underlying source of position information are flawed, not just those that check numerical values. The spec does not define how a UA should interpret the output of its underlying source of position information and what callbacks it should make as a result. For example, in test 39, setupDevice() is used to trigger an error condition by not providing a latitude, and the resulting error callback is checked. However, the spec does not specify that a missing latitude is an error, just that a success callback should not be made unless latitude, longitude and accuracy are present in the Position object. We could use a new triggerErrorCallback() JavaScript test function to test the properties of the PositionError object, but this means adding code to each UAs implementation which is test-specific and will probably exercise a different code path from that used in the normal flow. Unfortunately, setupDevice() also seems to be used without an argument by some tests to do some Opera-specific setup. I think we'll have to go through all of the tests individually to isolate those that are valid. On a related note, it would be good to remove from the test suite the concept of a server URL used to configure the UA, as not all UAs will use a server as a source of position information. Steve Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902
Received on Monday, 7 February 2011 19:56:55 UTC