Re: RfC: WebApps Testing Process

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

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

Maybe I am not understanding your proposal correctly. Could you flesh it 
out a bit more?

> 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))}

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

>> Comments on any of the above are welcome, especially regarding the
>> various "@@@ TBD: ..." tags that are sprinkled throughout the above
>> documents.
>>
>> A couple of questions too ...
>>
>> 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.

Received on Monday, 4 April 2011 14:23:45 UTC