W3C home > Mailing lists > Public > public-test-infra@w3.org > April to June 2011

Re: RfC: WebApps Testing Process

From: James Graham <jgraham@opera.com>
Date: Thu, 07 Apr 2011 10:57:41 +0200
Message-ID: <4D9D7C85.2040806@opera.com>
To: Garrett Smith <dhtmlkitchen@gmail.com>
CC: Aryeh Gregor <Simetrical+w3c@gmail.com>, public-test-infra <public-test-infra@w3.org>
On 04/07/2011 04:28 AM, Garrett Smith wrote:
> On 4/6/11, Aryeh Gregor<Simetrical+w3c@gmail.com>  wrote:
>> On Mon, Apr 4, 2011 at 7:12 PM, Garrett Smith<dhtmlkitchen@gmail.com>
>> wrote:
>>> I looked but I didn't see it where the spec says there's a global `Node`.
> \>  http://dev.w3.org/2006/webapi/WebIDL/#dfn-relevant-namespace-object
> So it's in WebIDL.
>> There is no enclosing module given for the Node interface in Web DOM,
>> so it's on the global object.
>>> To avoid the problems of generality, long functions, and typechecking.
>> What's wrong with generality, long functions, or typechecking?  (Long
>> functions aren't an issue at all, since it could always be broken up
>> into subfunctions.)
> Break it up. SRP for methods.
> Don't write functions that take any of number, string, object, and
> host object. That's just going to hide bugs. Look at any of the old
> discussions on jQuery. Then notice how the jQuery team tried to change
> the code the best they could to remove typechecking.

In general one needs all sorts of typechecking to *not* write methods 
that will accept any of string, number, etc. I don't see the advantage 
to having:

function assert_number_equals(expected, actual) {
   assert(typeof expected === typeof actual == "number");
   assert(expected === actual);

function assert_string_equals(expected, actual) {
   assert(typeof expected === typeof actual == "string");
   assert(expected === actual);

compared to just assert_equals that will take either type. Where 
*different* behavior is needed we already have a different assert_ 
function, for example assert_array_equals.

>>> All of these things open doors for quirks and gotchas,.
>> Like?
>>> Host object typechecking in particular is doomed to fail.

Note that we have the advantage that we are writing tests with the goal 
of making future browsers better. This is not code that has to work 
around issues in legacy browsers. In particular if a test fails because 
a browser has a bug relative to WebIDL, that is not a problem.

>> In what ways?
> I don't have time for this. Ask on comp.lang.javascript.

(that is not a helpful response).

> Try a few checks. Like typeof document.images typeof
> document.childNodes.item. Or do a web search for "unknown" type in
> IE9.

Ignoring the formatting code, there is very little typechecking in 
testharness.js. I think the only place it is used is in assert_throws. I 
think a legitimate comment might be "assert_throws should be split into 
separate functions for the DOM and non-DOM exception cases".
Received on Thursday, 7 April 2011 08:58:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:34:06 UTC