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