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

Chore: remove assert.doesNotThrow in tests #10199

Merged
merged 1 commit into from
May 22, 2018

Conversation

BridgeAR
Copy link
Contributor

What is the purpose of this pull request? (put an "X" next to item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[x] Other, please explain:

The assert.doesNotThrow API is not useful and just slows down the test run by
catching errors and then rethrowing in case of an error. In case
there is no error, it is a noop.

What changes did you make? (Give an overview)

Removed all assert.doesNotThrow calls and added a eslint rule to prevent any new additions.

Is there anything you'd like reviewers to focus on?

The wording for the error message.

@eslint-deprecated eslint-deprecated bot added the triage An ESLint team member will look at this issue soon label Apr 10, 2018
@platinumazure
Copy link
Member

I'll leave a note here that while I will defer to team consensus, I like assert.doesNotThrow for its explicitness and for if we were to change to a testing library that tracks individual assertions and so I (softly) object to its removal here.

Copy link
Member

@not-an-aardvark not-an-aardvark left a comment

Choose a reason for hiding this comment

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

Thanks for the pull request! I left a few suggestions for changes that I'd like to see if we do end up accepting this.

That said, I agree with @platinumazure -- I think assert.doesNotThrow is useful for explicitness. I doubt the performance impact is very significant.

@@ -109,7 +109,7 @@ describe("Validator", () => {
it("should do nothing with an empty config", () => {
const fn = validator.validate.bind(null, {}, "tests", ruleMapper, linter.environments);

assert.doesNotThrow(fn);
fn();
Copy link
Member

Choose a reason for hiding this comment

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

I think it would be better to convert these to direct calls, e.g.

validator.validate({}, "tests", ruleMapper, linter.environments);

tests/lib/cli.js Outdated
cli.execute(code);
});

cli.execute(code);
cli.execute(code);
Copy link
Member

Choose a reason for hiding this comment

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

This seems to me like the original assert.doesNotThrow call was redundant, so I think it can just be removed rather than duplicating this call.

);

// "Cache file should contain valid JSON"
JSON.parse(fs.readFileSync(CACHE_PATH, "utf8"));
Copy link
Member

Choose a reason for hiding this comment

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

Nitpick: Can you remove the quotes around these comments?

@BridgeAR
Copy link
Contributor Author

Comments addressed. About being explicit: often the tests are named as: abc should not throw. So it is already named. And IMHO adding a comment next to a code part that should not throw, is probably a better way of dealing with this.

@not-an-aardvark not-an-aardvark added evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion chore This change is not user-facing and removed triage An ESLint team member will look at this issue soon labels Apr 10, 2018
The API is not really useful and just slows down the test run by
catching errors and then rethrowing in case of an error. In case
there is no error, it is a noop.
@BridgeAR
Copy link
Contributor Author

Rebased due to conflicts.

@platinumazure
Copy link
Member

I missed this comment:

And IMHO adding a comment next to a code part that should not throw, is probably a better way of dealing with this.

So I'll go with consensus here. I withdraw my objections.

@platinumazure
Copy link
Member

@not-an-aardvark There have been some changes since your last review. Have your concerns been addressed?

@platinumazure platinumazure merged commit e25fc22 into eslint:master May 22, 2018
@platinumazure
Copy link
Member

Merged. Thanks for contributing and apologies for holding this up so long.

@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Nov 20, 2018
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Nov 20, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
archived due to age This issue has been archived; please open a new issue for any further discussion chore This change is not user-facing evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants