tracking: complete `std/expect`

[iuioiua]

The following APIs are currently not yet implemented in std/expect:

• [ ] toMatchSnapShot
• [ ] toMatchInlineSnapShot
• [ ] toThrowErrorMatchingSnapShot
• [ ] toThrowErrorMatchingInlineSnapShot
• [x] expect.anything #4366
• [x] expect.any #4366
• [x] expect.arrayContaining #4366
• [ ] expect.not.arrayContaining
• [x] expect.closeTo #4508
• [ ] expect.objectContaining #6065
• [ ] expect.not.objectContaining
• [x] expect.stringContaining #4508
• [ ] expect.not.stringContaining
• [x] expect.stringMatching #4508
• [ ] expect.not.stringMatching
• [ ] expect.assertions #6032
• [x] expect.hasAssertions
• [x] expect.addEqualityTester #4255
• [x] expect.addSnapshotSerializer #4537
• [x] expect.extend #4412

For those wanting to contribute, please submit one PR per API.

[raashidanwar]

Hey @iuioiua, I would love to contribute here.

[iuioiua]

Hey @iuioiua,

I would love to contribute here.

Great! Let us know which ones you'd like to work on, so there's no overlap with other's work.

[syhol]

As you start working on the async matchers, you might end up fixing https://github.com/denoland/deno_std/issues/3947 as a side effect.

[raashidanwar]

@iuioiua I will be picking.

expect.objectContaining
expect.not.objectContaining
expect.stringContaining
expect.not.stringContaining
expect.stringMatching
expect.not.stringMatching

[eryue0220]

Hi @iuioiua @raashidanwar Can I try for this too?

I'll pick

expect.assertions
expect.hasAssertions
expect.addSnapshotSerializer
expect.extend

[iuioiua]

Hi @iuioiua @raashidanwar Can I try for this too?

I'll pick

expect.assertions
expect.hasAssertions
expect.addSnapshotSerializer
expect.extend

For sure! Thank you. Please let us know if you need any help with anything.

[eryue0220]

Hi, @iuioiua

I have a question about is there a way that I can know whether the current Deno.test is completed or not?

[iuioiua]

Can you elaborate? Perhaps, something like this is what you're after.

let isTestDone = false;
Deno.test("my test", () => {
  ...
  isTestDone = true;
});

[eryue0220]

Can you elaborate? Perhaps, something like this is what you're after.

let isTestDone = false;
Deno.test("my test", () => {
  ...
  isTestDone = true;
});

Oh, sorry ~

What I mean that is there any methods that know the callback is done as for the Deno.test('test', callback)? If use a variable is a little tricky I think, because someone may write code like:

And expect.hasAssertions API is want to check if there were any assertions executed before, for example:

Deno.test('test suite', () => {
  expect.hasAssertion();
});

this will throw an error, there was no any assertions in test suite function at all . And the following code will pass:

Deno.test('test suite', () => {
    expect.hasAssertions();
    expect(1 + 2).toEqual(3);
});

On the other hand, why I know current test suite function is done or not, thus can throw an error exactly when the test suite function is completed.

[kt3k]

I don't think we have such hook in Deno.test. These are the current options of Deno.test https://deno.land/api@v1.40.2?s=Deno.TestDefinition

[eryue0220]

I don't think we have such hook in Deno.test. These are the current options of Deno.test https://deno.land/api@v1.40.2?s=Deno.TestDefinition

Is there any possibility to add some similar hook in deno_core, such as before and after?

[kt3k]

Is there any possibility to add some similar hook in deno_core, such as before and after?

Not sure if we are still open to such addition. When the last time we discussed similar topic, we decided to add test steps (See https://docs.deno.com/runtime/manual/basics/testing/#test-steps ). That essentially added hook capability to deno test.

So maybe it's a bit unlikely we add another hook capability to deno test, but I'm not completely sure.

[kt3k]

It might be non ideal, but maybe we can add support of expect.hasAssertions() only for describe it runners. They are wrappers of Deno.test and t.step, and we can add arbitrary hooks before and after it.

[eryue0220]

Is there any possibility to add some similar hook in deno_core, such as before and after?

Not sure if we are still open to such addition. When the last time we discussed similar topic, we decided to add test steps (See https://docs.deno.com/runtime/manual/basics/testing/#test-steps ). That essentially added hook capability to deno test.

So maybe it's a bit unlikely we add another hook capability to deno test, but I'm not completely sure.

Thanks for the information, but I think it's still not same as I mentioned before. Because t.step requires every developer to write their own assertion logic if they want to use expect.hasAssertion API. Or it will not work if use the api only.

[eryue0220]

It might be non ideal, but maybe we can add support of expect.hasAssertions() only for describe it runners. They are wrappers of Deno.test and t.step, and we can add arbitrary hooks before and after it.这可能并不理想，但也许我们可以仅为 describe it 跑步者添加 expect.hasAssertions() 的支持。它们是 Deno.test 和 t.step 的包装器，我们可以在其前后添加任意钩子。

It's also a good option, and can combine with deno_lint to do some limits.

[javihernant]

I'd like to work on: expect.anything expect.any expect.arrayContaining expect.not.arrayContaining

[timreichen]

Just out of interest: here the methods are called *Containing while native array api has includes and the assert mod uses *Includes . Is this intentional?

[javihernant]

Just out of interest: here the methods are called *Containing while native array api has includes and the assert mod uses *Includes . Is this intentional?

I think this is trying to imitate jest api. Take a look: expect.arrayContaining(array)

[timreichen]

I wonder if it would make sense to rename them to *Includes to align better with the web api and assert mod. They all call array.includes() under the hood and containing() has a very different meaning in Segments.prototype.containing() web api.

[kt3k]

I wonder if it would make sense to rename them to *Includes to align better with the web api and assert mod.

The expectation for std/expect is the compatibility to jest. Inventing new names here doesn't make sense to me.

[iuioiua]

For anyone wanting to contribute, we also need to make the Expected interface public (it's currently private) and include documentation, with examples, for each method.

[iuioiua]

@kt3k, is fn() supposed to be part of the public API?

[kt3k]

Yes, it corresponds to jest.fn https://jestjs.io/docs/mock-functions

[finleyjb]

I'm considering implementing objectContaining. Is anyone working on this?

[eryue0220]

I'm considering implementing objectContaining. Is anyone working on this?

Yes, I'm doing this now. You could try other API.

[rperryng]

Yes, it corresponds to jest.fn jestjs.io/docs/mock-functions

on that note, are there plans to improve the type-safety around fn() to match the type-safety of jest.fn()?

  // Create a new mock that can be used in place of `add`.
  const mockAdd = jest.fn<typeof add>();

  // `.mockImplementation()` now can infer that `a` and `b` are `number`
  // and that the returned value is a `number`.
  mockAdd.mockImplementation((a, b) => {
    // Yes, this mock is still adding two numbers but imagine this
    // was a complex function we are mocking.
    return a + b;
  });

(from: docs for jest.fn())

Since fn() currently is typed as Function, it returns any (which the typescript docs mention as a reason to avoid its usage).

(I hope this is the right place for this conversation, I couldn't find any other open issues that cover this topic yet)