RfC: WebApps Testing Process

D

dhtml

The W3C is building a test harness to test their APIs. It is not
necessary to provide workarounds for quirky IE behavior.

Here is the test harness:
http://w3c-test.org/resources/testharness.js

I noticed athat `format_value` does typechecking and handles host
objects. The method itself is longer than I care to post here but here
is the pertinent line:

| if (typeof val == "object" && val instanceof Node)

The problems I see with that are:
1) the typeof operator, for a host object is not specified to be
"object".
2) the method is too generic; nodes are not values; they're host
objects.

On point 1, I can't think of any browsers where nodes are callable,
however I can't think of any standard that says they must not be. And
furthermore, non-function host objects can and do violate ES 5. Opera,
last I checked, reported "object" for callable host objects (I suspect
that will change in the very near future, if not already). IE versions
flop on whether or not callable host objects result in "function",
"object", or "unknown".

Object (native or host and does implement [[Call]]) "function"
Object (host and does not implement [[Call]]) Implementation-defined
except may not be "undefined", "boolean", "number", or "string".

On point 2, I think the method could avoid complexity by being broken
up into another method. In thinking that, I though to look who's
calling format_value and saw that it's `assert_equals`.

The author thinks that overloading a method with primitives and host
objects is a fair approach. Otherwise, there would be too many
methods. I disagree that too many methods would be a problem. To me,
the large `format_value` method does way too much; more than its name
implies because to me, an object is an object and "value" implies a
primitive value (not getting distracted by "pass by value" details).


But for `assert_equals`:

| function assert_equals(actual, expected, description)
| {
| // (GS) Obsolete comment; indicates that the method does
| // (GS) two things, not one, and that htis is determined by
| // (GS) the parameters.
| /*
| * Test if two primitives are equal or two objects
| * are the same object
| */
| var message = make_message("assert_equals", description,
| "expected ${expected} but got $
{actual}",
|
{expected:format_value(expected), actual:format_value(actual)});
| // (GS) The caller should not be expecting anything to be
| // (GS) equal to NaN; write a new function and use isNaN.
| if (expected !== expected)
| {
| //NaN case
| assert(actual !== actual, message);
| }
| else
| {
| //typical case
| assert(actual === expected, message);
| }
| };
The author has an annoying habit of adding a semicolon to the end of
every FunctionDeclaration.

NaN can't be expected to be equal to anything, not here, not by the
author of the test function. Don't allow the caller to make
unreasonable assertions.

Kindly assist the author by pointing out and discussing mistakes in
the code.
 
G

Geoffrey Sneddon

The W3C is building a test harness to test their APIs. It is not
necessary to provide workarounds for quirky IE behavior.

Futhermore, it is reasonable to expect the ES3 subset of ES5 (i.e.,
the subset of ES5 which also has a definition in ES3 — even if it is a
conflicting one) to be correctly implemented.
NaN can't be expected to be equal to anything, not here, not by the
author of the test function. Don't allow the caller to make
unreasonable assertions.

assert_equals is effectively doing what the SameValue algorithm does
in ES5. Perhaps as such it'd be nicer if it were called
assert_samevalue, though that may well cause more confusion than it is
worth (test authors expecting an "equals" assertion, etc).

If the objection is that "equals" is defined to be something else in
the spec, in what case would we actually want any spec testsuite to be
checking values using the abstract equality algorithm? Using the
abstract strict equality algorithm would similarly seem problematic
under the this-isn't-equality-per-spec argument. If that's the reason
for the objection, then, to me at least, the gain from having
assert_equals actually match the abstract equality algorithm is
outweighed by the gain from having the assertion that should be used
to check the equality of values called what test authors expect.

(As for why we want the SameValue algorithm used to check equality,
when specs define what value should be returned by something, we want
to check that that value is returned, not one that happens to be equal
to it per the abstract equality algorithm or the abstract strict
equality algorithm.)

/gsnedders (Opera Software, but certainly not representing any
official views)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,997
Messages
2,570,240
Members
46,829
Latest member
KimberAlli

Latest Threads

Top