Re: Test suite issues

> 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