Open iuioiua opened 10 months ago
Hey @iuioiua, I would love to contribute here.
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.
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.
@iuioiua I will be picking.
expect.objectContaining
expect.not.objectContaining
expect.stringContaining
expect.not.stringContaining
expect.stringMatching
expect.not.stringMatching
Hi @iuioiua @raashidanwar Can I try for this too?
I'll pick
expect.assertions
expect.hasAssertions
expect.addSnapshotSerializer
expect.extend
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.
Hi, @iuioiua
I have a question about is there a way that I can know whether the current Deno.test
is completed or not?
Can you elaborate? Perhaps, something like this is what you're after.
let isTestDone = false;
Deno.test("my test", () => {
...
isTestDone = true;
});
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.
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
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
?
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.
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.
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.
It might be non ideal, but maybe we can add support of
expect.hasAssertions()
only fordescribe
it
runners. They are wrappers ofDeno.test
andt.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.
I'd like to work on: expect.anything expect.any expect.arrayContaining expect.not.arrayContaining
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?
Just out of interest: here the methods are called
*Containing
while native array api hasincludes
and the assert mod uses*Includes
. Is this intentional?
I think this is trying to imitate jest
api. Take a look: expect.arrayContaining(array)
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.
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.
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.
Yes, it corresponds to jest.fn
https://jestjs.io/docs/mock-functions
I'm considering implementing objectContaining
. Is anyone working on this?
I'm considering implementing
objectContaining
. Is anyone working on this?
Yes, I'm doing this now. You could try other API.
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)
The following APIs are currently not yet implemented in
std/expect
:toMatchSnapShot
toMatchInlineSnapShot
toThrowErrorMatchingSnapShot
toThrowErrorMatchingInlineSnapShot
expect.anything
#4366expect.any
#4366expect.arrayContaining
#4366expect.not.arrayContaining
expect.closeTo
#4508expect.objectContaining
#6065expect.not.objectContaining
expect.stringContaining
#4508expect.not.stringContaining
expect.stringMatching
#4508expect.not.stringMatching
expect.assertions
#6032expect.hasAssertions
expect.addEqualityTester
#4255expect.addSnapshotSerializer
#4537expect.extend
#4412For those wanting to contribute, please submit one PR per API.