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

Rules tend to be noisy in test frameworks #25

Open
nickserv opened this issue Mar 23, 2017 · 3 comments
Open

Rules tend to be noisy in test frameworks #25

nickserv opened this issue Mar 23, 2017 · 3 comments

Comments

@nickserv
Copy link
Contributor

nickserv commented Mar 23, 2017

Popular test frameworks like Mocha, Jasmine, and Jest encourage having many anonymous functions with assertions instead of return values. While this is inherently not a very functional paradigm, many functional libraries still use these test frameworks and it can be inconvenient to batch disable many rules at once.

Possible solutions

  1. Tell users to disable eslint in the test directory with an .eslintignore file. This is pretty drastic, but if we agree on this it wouldn't require any changes.
  2. Provide a configuration that disables all rules from this plugin. Unfortunately, eslint doesn't have an option for disabling all of a plugin's rules (see Provide means for disabling all rules from a given plugin within a file eslint/eslint#3419), so this would be a workaround.
  3. Provide a configuration that's similar to recommended, but friendlier to anonymous functions with assertions. This could disable rules like no-nil and no-unused-expressions. Users would then switch to this configuration only for test directories.
@graingert
Copy link
Collaborator

@nickmccurdy another solution is to recommend users us the Validation applicative function instead of asserts.

@nickserv
Copy link
Contributor Author

nickserv commented Aug 1, 2017

Thanks for the link. I've used applicatives in Haskell, and while it's a great pattern for general purpose pure functional programming, I'm concerned that this works against the much more imperative styles of almost all popular JavaScript testing frameworks (Mocha, Jasmine, Jest, Ava, Tape). I could use this pattern in my implementation, but I would need to use a test framework that only uses applicatives and pure results (which as far as I'm aware doesn't exist yet, though I've been experimenting with one. One could write their own testing infrastructure from scratch to meet these rules, but I feel like that's a lot of work for a linting library to impose.

What do you think about my possible solutions? I just converted them to a numbered list.

@janhesters
Copy link

@nickmccurdy I like your option 3, but this package seem to be unmaintained 😢
Option 1 is also okayish.

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

No branches or pull requests

3 participants