bind additional Assert functions

[illusionalsagacity]

• notEqual
• notDeepEqual
• strictEqual
• notStrictEqual
• deepStrictEqual
• fail

[cometkim]

Nitpicking, but can you replace it with t->expect style?

---

Maybe I should change the binding to t => x => expected instead of (t, x) => expected later version 🤔

[illusionalsagacity]

Maybe I should change the binding to t => x => expected instead of (t, x) => expected later version 🤔

Hmm, I kinda like that, you could alias expect in the start of your test function more easily that way too:

test("blah", t => {
  let expect = expect(t)
  ...
})

[illusionalsagacity]

@cometkim any others you think would be useful? I think these would be the most common for use in waitFor* or other exception-based callbacks in Vitest_Helpers. The number ones could be useful I suppose, but I figure it ought to be split into Int and Float (and I guess BigInt now too) sub-modules for those? for example:

let a = ref(0)
let b = ref(0.)
await waitFor(() => {
  Assert.Int.isAbove(a.contents, 0, ~message="a is 0")
})
await waitFor(() => {
  Assert.Float.isAbove(b.contents, 0., ~message="b is 0.")
})

[cometkim]

Well, I'm not a fan of exposing a bloated API surface upfront by providing bindings.

Some should strictly follow the binding style, but users should easily add or extend simple helper methods themselves. Most submodules of Assert as well as they are never associated with a test context.

[illusionalsagacity]

Well, I'm not a fan of exposing a bloated API surface upfront by providing bindings.

Are there any functions in here you would prefer not to be merged? Regardless I will leave out any more, to your point they should be straightforward enough to bind in consumer's projects

[cometkim]

If you use it in your project and you want to upstream it. I will merge unless there is a style conflict. Otherwise we can open issue and discuss first