[CommonJS] Re: [nodejs] assert.equal() and assert.throws()

[Alexander Teinum]

On Mon, Apr 26, 2010 at 10:50 PM, Karl Guertin <gray...@gmail.com> wrote:
> On Mon, Apr 26, 2010 at 4:45 PM, Alexander Teinum <ate...@gmail.com> wrote:
>> 1. Is there a good reason why equal() doesn’t use === as default? I
>> never use == myself, but in my tests I use equal() all the time –
>> which in my framework is like strictEquals().
>
> The API follows CommonJS:
>
> http://wiki.commonjs.org/wiki/Unit_Testing/1.0
>

I’ll add CommonJS to the discussion. I’m curious what others think
would be an ideal behavior for equal() now that the assert API has
been out there for a while.

>> 2. I would like to use throws() like this:
>>
>> test.throws(function() {
>>    var events = new WeekEvents([], [], [], []);
>> }, 'weekEvents must contain an array of events for each day.');
>>
>> Is that possible?
>
> Yes. Both the second and third argument are optional and omitting the
> error will do what you want.
>

I also need it to check the equality of the string since my WeekEvents
“class” will throw different messages depending on what I pass to the
constructor.


Alexander

--
You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.

[Kris Kowal]

On Mon, Apr 26, 2010 at 2:15 PM, Alexander Teinum <ate...@gmail.com> wrote:
> I’ll add CommonJS to the discussion. I’m curious what others think
> would be an ideal behavior for equal() now that the assert API has
> been out there for a while.

I've made a note in the errata. It's within the realm of possibility
that we might want to "fix" assert.equal, providing reflexive and
transitive guarantees, and move "loose" equal to another method. I
don't think that any existing tests depend on =='s bizarre edge cases,
and when they do, I don't think it would be onerous to upgrade those
cases.

http://wiki.commonjs.org/wiki/Unit_Testing

Kris Kowal

[Alexander Teinum]

Thanks for adding the note, Kris.

If

1. the CommonJS and the Node communities agrees that testing for loose
equality is generally a less good idea than testing for strict
equality

and if

2. testing for loose equality is the strange thing to do, and equal()
for that reason is not widely used

and if

3. …it’s used in a few cases, and a fix wouldn’t break the tests
(unless the test specifically targets the == quirks)

then

Wouldn’t it be the perfect moment to fix it right now?

For case 3, if the test would need changes because it targeted ==
quirks, having a looseEqual() would make the intent of that assert
even clearer. One wouldn’t even need to put a comment in the source
explaining what’s going on.

I also think all other assert functions should use ===, unless they’re
prefixed by “loose”.

For those that need a reminder how effed up == is, take a look at the
code examples in the first answer here: http://bit.ly/asxgN.


Any thoughts?


Alexander

[Kris Kowal]

On Tue, Apr 27, 2010 at 10:52 AM, Alexander Teinum <ate...@gmail.com> wrote:
> Wouldn’t it be the perfect moment to fix it right now?

Sure. For the CommonJS side of things, if you'd like to take charge
of driving the next version of the specification, go ahead and revise
this fork of the 1.0 specification and solicit discussion of your
proposal.

http://wiki.commonjs.org/wiki/Unit_Testing/B

Kris Kowal

[Alexander Teinum]

Great! I will have a look at it and keep you informed.


Alexander

[Alexander Teinum]

Great! I will have a look at it and keep you informed (forgot to click
“Reply to all”.)


Alexander

[Alexander Teinum]

There.

This is how my proposal differs from 1.0:

- Change assert.ok() test from “!!guard” to “guard === true”

- Change assert.equal() from using == to using ===

- Change assert.notEqual() from using != to using !==

- Remove assert.strictEqual()

- Remove assert.strictNotEqual()

- Add assert.looseEqual() that tests using ==

- Add assert.looseNotEqual() that tests using !=


http://wiki.commonjs.org/wiki/Unit_Testing/B

[Ash Berlin]

On 27 Apr 2010, at 19:53, Alexander Teinum wrote:
> There.
>
> This is how my proposal differs from 1.0:
>
> - Change assert.ok() test from “!!guard” to “guard === true”

This is the only one i have a problem with. My question is basically "why?"

>
> - Change assert.equal() from using == to using ===
>
> - Change assert.notEqual() from using != to using !==
>
> - Remove assert.strictEqual()
>
> - Remove assert.strictNotEqual()
>
> - Add assert.looseEqual() that tests using ==
>
> - Add assert.looseNotEqual() that tests using !=
>
>
> http://wiki.commonjs.org/wiki/Unit_Testing/B
>
>
> Alexander

Also what about the points on http://wiki.commonjs.org/wiki/Unit_Testing around deepEqual?

-ash

[Kris Kowal]

Any opinion about going "all the way" with assert.equal? This is a
snippet brought to my attention by Mark Miller some time ago of what
is necessary to make an equal operator "reflexive" in JavaScript.

function identical(x, y) {
if (x === y) {
// 0 === -0, but they are not identical
return x !== 0 || 1/x === 1/y;
} else {
// NaN !== NaN, but they are identical.
// NaNs are the only non-reflexive value, i.e., if x !== x,
// then x is a NaN.
return x !== x && y !== y;
}
}

Kris Kowal

[Kris Kowal]

Ash, I'm also interested in coercing you in some fashion into reverse
engineering a specification for deep equivalence comparison based on
that equiv implementation you trust.