Please use public-test-infra list for testharness.js discussions [Was: RfC: WebApps Testing Process]

Hi All - on March 31 I submitted a rough draft proposal to the WebApps 
WG related to testing processes [1]. That proposal includes re-using 
testharness.js which is used by at least the HTML WG and Web Performance 
WG. Garrett Smith submitted some comments about this harness and those 
comments are below.

Going forward, please use the following mail list for testharness.js 
discussions:

   public-test-infra@w3.org
   http://lists.w3.org/Archives/Public/public-test-infra/

Bugs for this harness should be submitted to the "Testing" product and 
"testharness.js" component:

   http://www.w3.org/Bugs/Public/describecomponents.cgi?product=Testing

James Graham (author of testharness.js) is default assignee of this 
component.

-Art Barstow

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/1086.html

-------- Original Message --------
Subject: 	Re: RfC: WebApps Testing Process
Date: 	Sun, 3 Apr 2011 16:45:02 -0700
From: 	ext Garrett Smith <dhtmlkitchen@gmail.com>
To: 	Arthur Barstow <art.barstow@nokia.com>
CC: 	public-webapps <public-webapps@w3.org>



On 3/31/11, Arthur Barstow<art.barstow@nokia.com>  wrote:

>  4. http://www.w3.org/2008/webapps/wiki/Harness - short intro to the
>  harness which is a reuse of the one used by the HTML WG (created and
>  maintained by James Graham)

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?

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.

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.

Received on Monday, 4 April 2011 13:21:31 UTC