assert.not() is confusing for a new user

[jzinn]

As a new user, I assumed that assert.not was equivalent to assert.is.not (using strict equality/inequality), while it is actually equivalent to assert.not.ok (using non-strict equality/inequality).

My initial reaction to this confusion is that it would be clearer (for me, a new user) if assert.ok and assert.not.ok were assertion methods, but assert.not was not an assertion method (i.e. the invocation assert.not() should result in the same error as the invocation assert()).

The situation would then be that these existed:

• assert.is
• assert.ok
• assert.is.not
• assert.not.ok

logicalness

However, even this is not ideal. Even though assert.is.not reads better than assert.not.is, the latter should be the one that exists because it is more logical and therefore is easier to remember. Then the list would be

• assert.is
• assert.ok
• assert.not.is
• assert.not.ok

refute

Additionally, assert.not could be implemented in terms of a refute module:

export * as not from "refute";

If refute were exposed to users, then they could write the following:

import { test } from 'uvu';
import * as assert from 'uvu/assert';
import * as refute from 'uvu/refute';

test('foo', () => {
  assert.not.ok(false);
  refute.ok(false);
});

[lukeed]

“Not is” is not grammatically sensible.
is.not and not.ok are the two exceptions for the entire module set, and it’s done for readability.

You’re welcome to create and export your own “refute” constant as all the built in assertions are standalone and composable.