Skip to content
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

Add eslint rule valid-expect #3067

Merged
merged 7 commits into from
Mar 6, 2017
Merged

Add eslint rule valid-expect #3067

merged 7 commits into from
Mar 6, 2017

Conversation

SimenB
Copy link
Member

@SimenB SimenB commented Mar 5, 2017

Summary
Adds a new eslint rule to pick up invalid usage of expect.

All credits goes to @tlvince and @alecxe, this code is 100% copy paste, including docs and tests (only change is how context.report is called, but it's called with the same args). Open question is how to credit them in the source code, and what should be done about the license header?
https://github.com/tlvince/eslint-plugin-jasmine/blob/master/lib/rules/valid-expect.js

Motivation: Especially when converting tests from other assertions libs, it's easy to miss something. Jest reports false positives for some misuse of the api.

Test plan
Run yarn lint on some code that uses expect in an invalid way. There actually was a test in the jest code base giving a false positive.

The diff from pretty-format-test.js is a good example of the errors this rule picks up.

@SimenB
Copy link
Member Author

SimenB commented Mar 5, 2017

/cc @jkimbo as well 😄

expect(prettyFormat('\"-\"'), '"\\"-\\""');
expect(prettyFormat('\\ \\\\'), '"\\\\ \\\\\\\\"');
expect(prettyFormat('\"-\"')).toEqual('"\\"-\\""');
expect(prettyFormat('\\ \\\\')).toEqual('"\\\\ \\\\\\\\"');
Copy link
Member

Choose a reason for hiding this comment

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

And this is the point where you proved the value of this rule! Thanks.

@@ -50,6 +51,7 @@ You can also whitelist the environment variables provided by Jest by doing:
- [no-disabled-tests](/packages/eslint-plugin-jest/docs/rules/no-disabled-tests.md) - disallow disabled tests.
- [no-focused-tests](/packages/eslint-plugin-jest/docs/rules/no-focused-tests.md) - disallow focused tests.
- [no-identical-title](/packages/eslint-plugin-jest/docs/rules/no-identical-title.md) - disallow identical titles.
- [valid-expect](/packages/eslint-plugin-jest/docs/rules/valid-expect.md) - disallow identical titles.
Copy link
Contributor

Choose a reason for hiding this comment

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

The description here doesn't look right

Copy link
Member Author

Choose a reason for hiding this comment

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

Indeed! Copy paste error

Copy link
Member

Choose a reason for hiding this comment

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

I'm working on it right now.

@@ -31,6 +31,7 @@ Then configure the rules you want to use under the rules section.
"jest/no-disabled-tests": "warn",
"jest/no-focused-tests": "error",
"jest/no-identical-title": "error",
"jest/valid-expect": "error",
Copy link
Member Author

Choose a reason for hiding this comment

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

This line is a breaking change btw. If the next release is not a major, this should be dropped

@cpojer
Copy link
Member

cpojer commented Mar 6, 2017

@SimenB I adjusted it a little bit, what do you think of that? Concretely I updated the message for expect(foo).toBeDefined. That rule now won't trigger if you don't have a matcher at all (like expect(…)) which already shows a different error, as well as it includes the name of the matcher. Does this make sense to you?

@@ -8,31 +8,37 @@
* @flow
*/

export type Identifier = {|
type Node = MemberExpression | CallExpression;
Copy link
Member Author

Choose a reason for hiding this comment

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

I started doing this, but my flow-fu failed me. Didn't know it'd be as little as this!

@SimenB
Copy link
Member Author

SimenB commented Mar 6, 2017

Looking at the changed assertions, that makes a lot of sense! Thank you for just blasting through and fixing the errors 😄

@cpojer cpojer merged commit e886064 into jestjs:master Mar 6, 2017
@cpojer
Copy link
Member

cpojer commented Mar 6, 2017

Nice! Thanks @SimenB for building this.

@SimenB SimenB deleted the valid-expect branch March 6, 2017 14:49
@@ -93,11 +93,11 @@ describe('matching cities to foods', () => {
});

test('Vienna <3 sausage', () => {
expect(isValidCityFoodPair('Vienna', 'Wiener Schnitzel'));
expect(isValidCityFoodPair('Vienna', 'Wiener Schnitzel')).toBe(true);
Copy link
Member Author

Choose a reason for hiding this comment

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

nice! 😀

skovhus pushed a commit to skovhus/jest that referenced this pull request Apr 29, 2017
* Add eslint rule `valid-expect`

All credits goes to @tlvince and @alecxe

* Update valid-expect.md

* Update valid-expect-test.js

* Update valid-expect-test.js

* Update valid-expect.js

* Minor fixes and cleanups.

* Fix lint errors.
tushardhole pushed a commit to tushardhole/jest that referenced this pull request Aug 21, 2017
* Add eslint rule `valid-expect`

All credits goes to @tlvince and @alecxe

* Update valid-expect.md

* Update valid-expect-test.js

* Update valid-expect-test.js

* Update valid-expect.js

* Minor fixes and cleanups.

* Fix lint errors.
@github-actions
Copy link

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.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants