Re: RfC: WebApps Testing Process

On 4/7/11, James Graham <jgraham@opera.com> wrote:
> 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.

Missing the point. The test harness function expects (it is designed
to take) any of number, string, host object, etc. Too general. There
is a difference between that and designing a method that expects a
string,

e.g. function padString(s, indent) { s = String(s); }

W

I don't see the advantage
> to having:
>
> function assert_number_equals(expected, actual) {
>    assert(typeof expected === typeof actual == "number");

A boolean value supplied to typeof will always result boolean.
(Remember, a program is parsed from left to right.)


>    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.
>

No, but more recent browsers do not agree on such things as
callability of HTMLFormControlsCollection, and, if callable, what the
result of typeof should be (ECMA says it must be "function").

>>>
>>> In what ways?
>>
>> I don't have time for this. Ask on comp.lang.javascript.
>
> (that is not a helpful response).
>

What did you search and what was your result?

>> 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
> testharness.js.

Generally optimistic but that does not address specific points.  And
the typechecking is just a quick thing that stood out. There's a lot
of problems there, James.

There is use of hasOwnroperty on a host object.  The problem with that
is there may be some sort of special [[Get]] for that object so even
Object.prototype is in that object's prototype it will fail.

anyone making assertions such as `assert(NaN, myvar)`, which the
harness accounts for, is making unreasonable expectations. The test
harness handles that misexpectation with:

| if (expected !== expected)
|        {
|            //NaN case
|            assert(actual !== actual, message);
|        }


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".
>
>

%^&
 Late.

Received on Thursday, 7 April 2011 14:47:08 UTC