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

no-new is incompatible with no-unused-vars in testing environments #762

Closed
Jakobud opened this issue Jan 24, 2017 · 3 comments

Comments

@Jakobud
Copy link

commented Jan 24, 2017

no-new and no-unused-vars is a weird combination of rules when it comes to building tests. For example, I want to test that an error is caught when instantiating an object incorrectly using Mocha for testing:

asset.throws(function () {
  new MyObject();  // object is expecting parameters but I'm not providing them in order to purposely force an error to be thrown
})

Because I'm missing some parameters when instantiating my object here, I would expect my object to throw an error, which is does and Mocha tests it correctly. However, new is used by itself without assigning it to a variable and StandardJS does not like this. So easy fix right:

asset.throws(function () {
  let foo = new MyObject(); 
})

Fixed one issue but introduces another. Now StandardJS does like this because foo is defined but not used.

What am I supposed to do in this situation? Seems kind of bogus that I would to write additional dummy code to use foo just to satisfy StandardJS. Any advice?

@feross

This comment has been minimized.

Copy link
Member

commented Jan 24, 2017

Both these rules are usually quite useful in the general case, but there are always circumstances where you may need to override certain rules. standard provides an easy mechanism for this. Just add a comment:

asset.throws(function () {
  new MyObject() // eslint-disable-line 
})

This is documented here: http://standardjs.com/#how-do-i-hide-a-certain-warning

@feross feross closed this Jan 24, 2017

@Jakobud

This comment has been minimized.

Copy link
Author

commented Jan 24, 2017

Oh man I don't know how I missed that option. Thank you,

@feross

This comment has been minimized.

Copy link
Member

commented Jan 24, 2017

No problem!

@lock lock bot locked as resolved and limited conversation to collaborators May 10, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
2 participants
You can’t perform that action at this time.