Googling for "mocha arrow functions" I came across this package. First of all, of course, thanks for making this available. However, I after some consideration, I am not sure this is the way to go:
- The required setup (adding
import { it, before, after, beforeEach, afterEach } from 'arrow-mocha' at the top of every file) seems more trouble than it's worth.
- The extra
t parameter changes the standard API of mocha functions, which may be confusing for a developer expecting the regular mocha API.
- It feels like a hack: if you really don't want the lexical binding of
this, using regular functions seems perfectly fine too.
Did you consider just using local variables instead?
describe('test suite', () => {
let myObj
before(() => {
myObj = new MyAwesomeThing()
})
it('some test', () => {
console.log('myObj is:', myObj)
})
})
This seems much more explicit and with fewer moving parts and no external dependencies.
This will work for a "base test" of sorts as well:
import sinon from 'sinon'
function baseTest() {
const ctx = {}
beforeEach(() => {
ctx.sandbox = sinon.sandbox.create()
})
afterEach(() => {
ctx.sandbox.restore()
})
return ctx
}
describe('some function', () => {
const t = baseTest()
it('is called', () => {
t.sandbox.spy(someFunc)
someFunc()
expect(someFunc).to.have.been.calledOnce
})
})
Perhaps you would consider documenting this alternative approach in your README?
Googling for "mocha arrow functions" I came across this package. First of all, of course, thanks for making this available. However, I after some consideration, I am not sure this is the way to go:
import { it, before, after, beforeEach, afterEach } from 'arrow-mocha'at the top of every file) seems more trouble than it's worth.tparameter changes the standard API of mocha functions, which may be confusing for a developer expecting the regular mocha API.this, using regular functions seems perfectly fine too.Did you consider just using local variables instead?
This seems much more explicit and with fewer moving parts and no external dependencies.
This will work for a "base test" of sorts as well:
Perhaps you would consider documenting this alternative approach in your README?