-
Notifications
You must be signed in to change notification settings - Fork 150
feat: expand async matcher support #1040
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
base: main
Are you sure you want to change the base?
feat: expand async matcher support #1040
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1040 +/- ##
==========================================
+ Coverage 96.30% 96.49% +0.18%
==========================================
Files 47 49 +2
Lines 2542 2679 +137
Branches 1047 1110 +63
==========================================
+ Hits 2448 2585 +137
Misses 94 94 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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.
Thanks for your contribution! I added some comments, but the implementation seems fine in general.
if ( | ||
isCallExpression(node) && | ||
ASTUtils.isIdentifier(node.callee) && | ||
node.parent && | ||
isMemberExpression(node.parent) && | ||
node.callee.name === 'expect' | ||
['expect', 'expectAsync'].includes(node.callee.name) |
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 sure if we should check that expect
is combined with the right subset handlers (resolves
, rejects
, etc), and expectAsync
is combined with its subset handlers (toBeRejectedWith
, toBeResolved
, etc).
I think it's fine as it is, so we don't need to check if the combination between expect and matcher exists, as the code won't work if doesn't.
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 had the same thought and came to the same conclusion. there will be plenty of other signals elsewhere if an incompatible combination is used - TS, runtime errors, etc.
@@ -261,6 +261,24 @@ ruleTester.run(RULE_NAME, rule, { | |||
` | |||
), | |||
|
|||
// jasmine async matchers are valid |
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 trying to think any invalid case that should be added, but there is none probably, since the improvement only includes more valid combinations.
Checks
Changes
This expands support for additional async matchers (specifically, jasmine) to reduce false positives for
await-async-queries
andawait-async-utils
. As mentioned in the linked issue, I understand any hesitancy to include framework-specific logic, but I think this is a relatively trivial addition to open up support to another testing framework.Context
Fixes #1039