More Unit Test spec bugs

[Ash Berlin]

So, looking at implementing the unit test proposal (using narwhal's impl) I noticed a spec buglet:

assert.equal(4, new Number(4));
assert.deepEqual(4, new Number(4));

The first one passes, the second does not. Self-consistency is a good thing :) I'm creating a list of things to address in the next version on http://wiki.commonjs.org/wiki/Unit_Testing/

What was the outcome of the throws alias/rename? Has that changed since ES5 is now a ratified spec?

-ash

[Wes Garland]

> What was the outcome of the throws alias/rename? Has that changed since ES5 is now a
> ratified spec?

I think we should be pragmatic here and continue to support strict ES3 engines unless there is a compelling reason NOT to.

Who knows, somebody might want to run this in internet explorer.

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Ash Berlin]

On 6 Dec 2009, at 17:36, Ash Berlin wrote:

So, looking at implementing the unit test proposal (using narwhal's impl) I noticed a spec buglet:

assert.equal(4, new Number(4));
assert.deepEqual(4, new Number(4));

Another possible issue - this time i think its just an issue with the narwhal version:

7.4 says "... equivalent values for every corresponding key, and an identical "prototype" property"

The test for this in Kris Kowal's fork has:

exports['test deepEqual ["a"], {0:"a"}'] = makeBlock(assert.deepEqual, ["a"], {0:"a"});

These two object types don't share a prototype. However the spec is worded wrong here as they do share an identical "prototype" property -- that is, neither object has one. Object.getPrototypeOf is the ES5 method that is wanted here instead (the portable way for the old __proto__ property). If the intent was to actually to check the prototype property and not the internal [[Prototype]], well then I'm not quite sure what to say.

-ash

P.S. Stupid wiki doesn't like trailing slashes in urls: http://wiki.commonjs.org/wiki/Unit_Testing