Re: RfC: WebApps Testing Process

On 3/31/11, Arthur Barstow <art.barstow@nokia.com> wrote:
> Hi All,
>
> During the 2011 TPAC meeting, I agreed to an action (action-611) to work
> with Chaals and WebApps' Team Contacts to define the group's testing
> processes.
>
> To that end, I created the following documents:
>
> 1. http://www.w3.org/2008/webapps/wiki/Testing - some high level goals,
> and links to other related resources.
>
> 2. http://www.w3.org/2008/webapps/wiki/Submission - licensing info, test
> repository structure and how to submit tests. Notes: a) since WebApps
> will have a test suite per spec, the proposed structure is different
> than the structure used by HTML WG; b) if the proposed structure is
> accepted, some of WebApps existing dirs in Hg will need to be moved.
>
> 3. http://www.w3.org/2008/webapps/wiki/Approval - how to start a test
> case review, approval process, how to update an approved test case
>
> 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.

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

Received on Sunday, 3 April 2011 23:55:58 UTC