Testing module compatibility

At the minute we don’t really seem to follow node’s assertion interfaces or anyone else’s.

Is there any reference as to what convention was followed or was it thought up just for deno?

It may be worth rewriting the testing module to adhere to node’s assertion module and be entirely compatible.

Basically current implementation:

assertEqual(actual, expected, msg);
assert(equal(actual, expected), msg);

Node implementation:

assert.equal(actual, expected, msg);

So:

• assertEqual doesn’t seem to be needed, only for setting a nice message (deepEqual and equal would do this themselves)
• equal does a deep equality check for us but in node does an Object.is alone (as deepEqual exists for the former)
• An AssertionError is thrown rather than an Error in node
• Negated functions exist in node such as notEqual

[kitsonk]

Personally I would rather take queues from Chai assert personally.

The behaviour of assertEqual() and equal() is already established, both in all of std but also the core of Deno. There is a lot of tests that depend upon that deep comparison behaviour.

I don’t think we should be pedantic about following anyone else’s behaviour. We can take queues and patterns from others. The benefit of TypeScript and JSDoc is that the APIs can be self documenting if there is any confusion.

[43081j]

The reason for equal being simple (value equality check, usually) is that we can then have a deepEqual for when we want recursive equality checks. Leaving equal to do a deep check seems fine as long as we then have a strictEqual or similar, for when we don’t want deep equality (which would be Object.is pretty much).

I agree with your rejects idea, too, but it could be argued that both should be supported in that case. If dealing with promises directly, it sounds logical to have rejects and resolves, but if dealing with async functions, it sounds logical to have throwsAsync and returnsAsync. Really depends on what context you’re in.

Anyhow, i’m happy to open a few issues separately about these things but the idea of this issue in particular was to identify what those are.

Also, there’s now equal and assert.equal being exported which can be a little confusing (one doesn’t assert). It probably shouldn’t be exposed anymore but again would need a bunch of updates to other modules.