Add and configure eslint-plugin-mocha

[papandreou]

The main use case for me is to prohibit it.only from being pushed accidentally.

I enabled the rules that seemed most useful and hopefully not too controversial, but there are more: https://github.com/lo1tuma/eslint-plugin-mocha/blob/master/docs/rules/README.md

[sunesimonsen]

Why the arrow function hate 😊

[papandreou]

Arrow functions are bad in mocha tests because they prevent you from accessing the test context via this. More background here: mochajs/mocha#2018

[papandreou]

(however, since we also want the test suite to run in jest, which doesn't have the concept of a test context, we don't really rely on it anywhere).

[sunesimonsen]

I don't think we want to use this in the tests are you mention.

[sunesimonsen]

I would like to remove the arrow functions constraint. But if you want to keep it I'm also okay with that.

[papandreou]

I've wired up my brain so arrow functions with it and describe smell bad, because it rubs mocha the wrong way, but I could make my peace with that.

Inconsistency bothers me even more though -- so if we decide against including that rule, I think we should switch to arrow functions everywhere: #522

[alexjeffburke]

I'm sort of torn - I actually had no idea that there was a functionality penalty using arrow functions with mocha. If I may ask, what is the use case for the mocha context API?

I've always just been consistent with what each project currently does. In $work trees we do arrow functions for it/describe and I'd be surprised if many people reach for the feature.

In summary I defer to those with stronger feelings - I'm perfectly happy to keep the constraint and relax it later since we already uphold it or convert wholesale.

[papandreou]

@alexjeffburke, the mocha test context can be use for building up state in beforeEach blocks, similar to using variables lexically scoped to eg. a describe block. That part is mostly a matter of taste.

Another use case is to install a test suite-wide feature or "plugin", for example something like https://www.npmjs.com/package/mocha-sinon, without adding a beforeEach that creates a new sinon sandbox to each test file. To some extent that's analogous to putting the sandbox in a global variable, so again a matter of taste and aesthetics.

... All of this doesn't matter so much anymore, though, as I already reverted the parts that prohibited arrow functions in describe and it. I've opened another PR so we can consistently use arrow functions instead. We aren't likely to start using the mocha context because jest doesn't support it.

Seems like everyone is on board with the other parts, so I'll merge :)