Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

chore: add prefer-to-contain rule #174

Merged
merged 1 commit into from
Oct 14, 2018

Conversation

katakonst
Copy link
Contributor

fixes #100

`expect(a.includes(b)).toEqual("test")`,
`expect(a.includes(b)).toBe("test")`,
`expect(a.includes()).toEqual()`,
`expect(a.includes(b)).toBe(false)`,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we support this, and suggest expect(a).not.toContain(b)?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree on supporting the .not.toContain() syntax. 👍

Copy link
Contributor Author

@katakonst katakonst Oct 14, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added not.toContain suggestion

@SimenB SimenB requested a review from macklinu October 13, 2018 07:41
@katakonst katakonst force-pushed the feature/prefer-to-contain branch 2 times, most recently from 8227f3e to 14bb2a1 Compare October 14, 2018 14:33
Copy link
Member

@SimenB SimenB left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Left a couple of inline comments, but this is looking really good 🙂

```

```js
expect(a).toContain(b);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

node.arguments[0].arguments.length === 1 &&
node.arguments[0].arguments[0]
) {
const sourceCode = context.getSourceCode();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we move all these variables into the the fix closure to avoid the hit of calculating them unless people call fix?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved

create(context) {
return {
CallExpression(node) {
if (
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this if is really verbose, could you clean it up? Not a bigge (we can do it later), but 15 lines seems excessive

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Broke it in multiple methods

CallExpression(node) {
if (
!(
expectNotCase(node) ||
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about e.g. expect(a.includes(b)).not.toEqual(true);? might be weird enough that we don't need to support it, I guess 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'a a little weird but it's a nice to have. Added it to the rule!

@katakonst katakonst force-pushed the feature/prefer-to-contain branch 2 times, most recently from 8335e71 to 254bca7 Compare October 14, 2018 17:18
return getNegationFixes(node, sourceCode, fixer).concat(fixArr);
}

const equalityArgument = isEqualityNegation(node)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI is complaining that this line is not covered by tests. Mind adding a test for the other case (or removing the ternary)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was not used so removed it, the coverage is fine now.

@katakonst katakonst force-pushed the feature/prefer-to-contain branch from 254bca7 to 9358170 Compare October 14, 2018 17:32
Copy link
Member

@SimenB SimenB left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great, thank you so much for sticking with us!

@SimenB SimenB merged commit 83a4c48 into jest-community:master Oct 14, 2018
@SimenB
Copy link
Member

SimenB commented Oct 14, 2018

🎉 This PR is included in version 21.25.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

New rule prefer-to-contain
3 participants