-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(expect, @jest/expect): support type inference for function parame… #13268
Conversation
…ters in CalledWith assertions
Hi @royhadad! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at [email protected]. Thanks! |
Would be nice to add type tests here: Also note that aliased matchers will be removed with the next released. Perhaps it would make sense to add the new test targeting only non-aliased matcher? EDIT: to run the type tests, you have to build the library and then |
Thanks! Can you add some type tests? https://github.com/facebook/jest/tree/main/packages/expect/__typetests__ You run them with |
packages/expect/src/types.ts
Outdated
@@ -118,32 +118,39 @@ export interface AsymmetricMatchers { | |||
stringMatching(sample: string | RegExp): AsymmetricMatcher; | |||
} | |||
|
|||
type PromiseMatchers = { | |||
// if T is a function, return its parameters array type, otherwise return an unknown array type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm.. In this use case, can it be not a function? I mean, isn’t it that toHaveBeenCalledWith
should be used with functions. Or?
I just look at toMatchSnapshot
again thinking that constraining types for the matcher would make sense here too. Do I miss something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mrazauskas
Yes, toHaveBeenCalledWith
should only be called on functions, but we don't have a way to constrain it at that level (because the Matcher
also handles non-function matchers. I tried doing something on this branch but it is not really possible.
So to sum up, yes, in this use case it can still not be a function (and will likely fail the test at run time)
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
Co-authored-by: Tom Mrazauskas <[email protected]>
I've added a single automated test (for now), but can't make it pass on my local machine. Any idea what I'm missing? |
Do you see an error in IDE?
|
@mrazauskas |
Co-authored-by: Tom Mrazauskas <[email protected]>
Co-authored-by: Tom Mrazauskas <[email protected]>
CHANGELOG.md
Outdated
@@ -2,9 +2,10 @@ | |||
|
|||
### Features | |||
|
|||
- `[feat(@jest/environment, jest-runtime)]` Allow `jest.requireActual` and `jest.requireMock` to take a type argument ([#13253](https://github.com/facebook/jest/pull/13253)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wanna send a separate PR for these to changes? That way CI will trigger when you push without me having to press a button 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not totally sure what you mean, maybe suggest a change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extract the removal of feat
from the changelog to a separate PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried doing that and the workflow did not automatically run: 8969360
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I meant make those changes in a separate PR which I'll merge. Then approval is no longer needed (once you have a merged contribution)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure
@SimenB @mrazauskas |
Co-authored-by: Tom Mrazauskas <[email protected]>
One test is failing due to a timeout, I don't think it has anything to do with my PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice!
@@ -217,6 +217,38 @@ expectType<void>(expect(jest.fn()).toBeCalledWith('value', 123)); | |||
expectType<void>(expect(jest.fn()).toHaveBeenCalledWith()); | |||
expectType<void>(expect(jest.fn()).toHaveBeenCalledWith(123)); | |||
expectType<void>(expect(jest.fn()).toHaveBeenCalledWith(123, 'value')); | |||
expectType<void>(expect(jest.fn()).toHaveBeenCalledWith(123, 'value')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
expectType<void>(expect(jest.fn()).toHaveBeenCalledWith(123, 'value')); |
same as above, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice catch! This was not on purpose :)
Co-authored-by: Simen Bekkhus <[email protected]>
Fixed 😊 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is awesome, thanks!
As for backwards compat, I think this is fine. Some tests might break if you typecheck them, but if you typecheck your tests you probably want that.
If people complain we can always revert and re-land in the next major
It looks like this PR is causing typechecking failures for us. I see @SimenB says that this may be expected for buggy tests, but my tests don't look obviously wrong to me. CI failure: https://app.circleci.com/pipelines/github/apollographql/apollo-server/17609/workflows/e4053b3a-7b24-457e-be76-5f4786248ddc/jobs/139043 It seems like the issues specifically relate to |
See #13339. Indeed the asymmetric matchers like |
Thanks, that release fixes our tests! This does seem like a cool feature if it gets polished. |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
…ters in
CalledWith
assertionsSummary
Closes #13267
Let me know where I missed something, I'm a first-time contributor 😊
Test plan
To test it out, either use
expect
orjestExpect
withtoBeCalledWith
, you should get automatic type inference for the function arguments assertion.Any ideas for a way to add an automated test?