-
Notifications
You must be signed in to change notification settings - Fork 22
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
New rule: No arrow function expression as test callback #24
Comments
Excellent call, agree that it should be on test and module callbacks, consider this accepted (until I can get to a desktop and apply the label). Thoughts on rule name? I'm thinking |
I'll start work on this. @mitchlloyd Do you think there should be an option to tolerate arrow functions if they don't refer to |
I don't have any interest in allowing people to use both |
@mitchlloyd I'm with you on that-- I'm just trying to figure out if there might be others who would want the linter to only flag it when someone is actually relying on It's easy to add this later if someone wants it, so I guess for now I'll go with no arrow functions period. In that case, I'm pretty close to having a branch ready. |
I've put up a new branch. Could you take a look at the documentation in that branch to make sure I haven't misrepresented anything (especially about arrow functions, which I don't regularly use)? Thanks! |
arrow functions and their context binding are important note: qunitjs/eslint-plugin-qunit/issues/24#issue-137707265 also in case this.stub ever fails, simply use sinon directly `sinon.stub`
As arrow functions become more commonly used, developers may use them to create QUnit
test
callbacks. This changes the expected test context to something else (probably towindow
). Some testing setups have specializedmodule
s that usethis
insidebeforeEach
to manipulate the context, so changing it can be problematic.Example that should warn:
Example that is ok:
I haven't thought too much about implementation yet, but it seems fairly simple to look for the test callback and then ensure that an arrowFunctionExpression is not being used.
It might also make sense to apply this rule to the
beforeEach
andafterEach
callbacks inmodule
setup.The text was updated successfully, but these errors were encountered: