Re: RfC: WebApps Testing Process

On 4/4/11, James Graham <jgraham@opera.com> wrote:
> (setting followup to public-testinfra)
>
> On 04/04/2011 01:45 AM, Garrett Smith wrote:
>
>> I'd rather see the `format_value` function broken up. It makes
>> non-standard expectations of host objects (`val`) and that there is a
>> global `Node` object. Which standard requires that?
>
> Well Web DOM Core does. I assume DOM Core 2 also does but I'm not sure
> where the IDL variant it uses is specified.
>

I looked but I didn't see it where the spec says there's a global `Node`.

>> Instead of making decisions based on what is on the object's prototype
>> chain, It is safer to make a more direct inference.
>>
>> However, taking a step back, I want to know why the function is so
>> generalized.
>>
>> I see that the function `format_value` is called by `assert_equals`
>> and by itself, recursively. It is expected to take all of number,
>> string, and Node because assert_equals pushes down the requirement to
>> be generalized. I would rather see this functionality broken up so
>> that assertions about Node objects are passed Nodes, and then the
>> formatting can be in format_node, or stringify_node, etc. And it can
>> get worse when you have more object types or subtypes, such as any of
>> the various DOM collections.
>
> That doesn't obviously sound like a win. Why would we want to implement
> one function per type when there could be huge numbers of types, weak
> typing is idiomatic javascript, and the langauge doesn't make
> implementing type-specific functions easy?
>
To avoid the problems of generality, long functions, and typechecking.

All of these things open doors for quirks and gotchas,. Host object
typechecking in particular is doomed to fail. We discussed this for
years on c.l.js and with many examples from the popular libraries like
jQuery, Dojo, and Prototype.js.

> Maybe I am not understanding your proposal correctly. Could you flesh it
> out a bit more?
>
Yeah, a little below.

>> I've attacked this `assert_*` multiplicity variance by using what is
>> called "constraints" in NUnit. Essentially, "encapsulate the parts
>> that vary. In javascript, a constraint can be written very easily as a
>> function. That will also allow for cleanup of the messiness of `-0`
>> and NaN's and their accompanying obsolete comments.
>
> So as far as I can tell, NUnit syntax would give a syntax like
>
> assert(4, equals(function() {return 2+2}))
>
> Or, perhaps, more like
>
> test(function() {assert(4, equals(2+2))}
>
That would be an assertEquals assertion for numbers.

Assert.that = function(constraintFunction, message) {

};

Method `Assert.that` either throws an AssertionError or it doesn't.

Function `constraintFunction` does whatever does and is expected to
return a string. If that string is non-empty, it means that there was
an error message of the constraintFunction and can be used as an error
message to the failed test.

The `message` param is an optional additional message which usually
isn't needed but might be useful in some cases for an additional
message. For example, if there is a situation where the test fails,
you might supply something like "don't move your mouse; it makes the
test fail.".

> So far I have not really understood why this is an improvement.
>
I see.

If the problems with long functions, generalized functions, overloaded
typechecking functions are not understood then refactoring the code to
not do thost things won't seem very worthwhile.

[...]
>>> 1. What is the level of uptake of testharness.js within the HTML WG
>>
>> What is the HTML WG using a javascript test harness for?
>
> Running in-browser automated tests.
>
Is the HTML WG doing something with the javascript? Seems kind of strange to me.
-- 
Garrett

Received on Monday, 4 April 2011 23:15:46 UTC