Mocha: this.timeout() fails when using ES6's arrow functions

It binds the function to the test context, which can't be done when using arrow functions. From http://mochajs.org/

Sorry about that!

Thanks.

Why so many "magic" that, at the end, produces problems? Why not this?:

var mocha = require('mocha');

mocha.describe('foo', (suite) => {
  suite.timeout(100);

  suite.it('must love bar', () => ... );  
});

No globals, no problematic magic... but just JavaScript.

What you're proposing is a major breaking change and something that's being discussed in https://github.com/mochajs/mocha/issues/1969#issuecomment-160925915 A rewrite might introduce those types of semantics :)

Nice to know. Thanks.

@ibc well, it would have to be

var mocha = require('mocha');

mocha.describe('foo', (suite) => {
  suite.timeout(100);

  suite.it('must love bar', (suite) => ... );  
});

but are the two different suite arguments the same type? probably not, so then you have different variable names to reflect the different types like so

var mocha = require('mocha');

mocha.describe('foo', (suite) => {
  suite.timeout(100);

  suite.it('must love bar', (test) => ... );  
});

anyway, the arrow operator cannot be used in functions that expect contexts.

I don't envision breaking the BDD UI for #1969--right off the bat, anyway--though I could be persuaded. It was my hope that we keep the existing API, and introduce a separate package containing the BDD UI. Mocha will ship with a version of the BDD UI which uses the existing API, but then we can release a new version of the BDD UI package using lambdas thereafter--users can choose whether or not to explicitly upgrade to that package.

Maybe alternative ES6 syntax for describe or suite wrapper might solve this problem:

describe({ feature: 'create stuff' , do () {
    it('abc', () => {
    }); 
}})

This would at least allow binding at the suite level.

Any update on this? I have this

mocha = require('mocha');

mocha.describe('test', (suite) => {

suite.timeout(500);

suite.it('test', (done)=>
          )
    }
)

And getting TypeError: Cannot read property 'timeout' of undefined

@mroien this is not a Mocha bug. the arrow syntax is not a 1:1 replacement for function. please read up on its limitations

Did anything come of this? I like the proposed solution, if only for my love of arrow functions and aversion to 'this' when it's not required

Since timeout is only relevant with done, why not simply attach the timeout function to the done function.

it('makes sense', done => {
    done.timeout(100);
});

@nomilous this still doesn't work. I've had a similar problem. What works for my case is calling setTimeout inside the it block. e.g.

it('description', done => {
     const func = () => {
          // assertions
     };
     setTimeout(func, 10000);
});

@nomilous synchronous or cases returning a promise can also have a timeout.

@andela-engmkwalusimbi this isn't supposed to work. As @boneskull wrote:

@mroien this is not a Mocha bug. the arrow syntax is not a 1:1 replacement for function. please read up on its limitations

For everyone still wondering about this, ensure you understand what an arrow function implies, then come back here and read on (there are plenty of resources out there that can explain this far better than I can).

The only way this arrow functions would work in this case is if we change the bdd API to pass a context object to every Runnable's (hooks, tests) callback, instead of leveraging this. That's not a bad idea, but it's an earthquake of a breaking change, so will never happen. Instead of this:

it('should do something', function (done) {
  this.timeout(9000);
  // stuff
  done();
});

it'd look like this:

it('should do something', (context, done) => {
  context.timeout(9000);
  done();
});

That'd would break every async Mocha test in existence, regardless if it was backwards-compatible otherwise:

it('should do something', function (context, done) {
  // context is unused, but 'done' is now the second parameter
  this.timeout(9000);
  done();
});

We could provide an alternative bdd implementation that does this, however--it just wouldn't be the default.

That's about the most thorough explanation I have of "where this issue is at". :smile:

Maybe it could be taken into consideration for the next major version? I don't think it's an important enough change to create an alternative bdd implementation. Having named arguments might help with future development too and maybe create a simple way to add some kind of test middleware like so:

it('should do something', function ({ context, done }) { ...

We could provide an alternative bdd implementation that does this, however--it just wouldn't be the default.

@boneskull A new bdd-es6 interface would be great :)

Although I am in love with arrow functions which are really useful for e.g. Array functions like .filter(i => i.val), what's the problem with using normal functions? I think it's quite useful to have describe and it globally so I don't have to require them each time. Also since when is this magic, only because you don't understand (arrow) functions? I definitely don't want to provide a variable each time when I can return promises, otherwise I would have switched to something like ava a long time ago. Regarding the simplicity of mocha I think there shouldn't be any large change on normal/arrow functions described in #1969. And please don't tell me arrow functions are faster to type since your editor can transform a single f into function () {\n\t\n}.

i'm unclear, is there a solution to timeout out a before() call that uses arrow functions?

    before( async function () {
      data = await provider.getData();
      console.log(data);
      this.timeout(30*1000);
    });

Has no effect. still getting 4 second timeout here. This is the only slow thing in my test suite. I can put timeout to 30s in mocha.opts to solve the problem, but I don't really need all tests to timeout after 30s just the one api call when 4s is fine for 99% of them.

Here's how I solved it in the meantime (note that the first describe() uses function instead of fat arrow syntax:

describe('Search API', function () {
    this.timeout(30*1000);

    context('search', () => {
        let data;

        before( async () => {
          data = await provider.getSearch();
        });

        it('returns results', () => {
          expect(data).to.exist;
          expect(data.results).to.be.instanceOf(Array);
          expect(data.results.length).to.be.above(0);
        });
    })
});

@chovy You're setting the timeout after the timeout occurs in await provider.getData().
Try using this instead:

before(async function () {
  this.timeout(30*1000); // set timeout first, then run the function
  data = await provider.getData();
  console.log(data);
});

i'm unclear, is there a solution to timeout out a before() call that uses arrow functions?

Just to be clear on this: there is currently no way to call Mocha's timeout using arrow functions. Any discussion of alternatives (however meritorious) is discussion about possible new (or at least modified) interfaces.

Something I've had in my mind for a while was being able to do:

it('...', (done) => {
  ...
  done()
})

and

it('...', (t) => {
  t.timeout(500)
  t.tag('integration', 'api')
  ...
  t.done()
})

using the same default interface.

Supporting both in the same default interface let's you start using arrow functions in an existing codebase. Worth pointing out that the (done) syntax found in many tutorials online would still work, without flags or anything.

So in this implementation, you get as parameter the traditional done function, but with the utility functions added as properties of that done function object.

using this.timeout() causes elapsed time to disappear in report.

@dasilvacontin no idea why we didn't think of that earlier. that's an excellent idea.

@dasilvacontin oh, I remember. because you have to call it. you might not want to.

Sorry, can you elaborate on "have to call it", @boneskull? Are you talking about the problems where Mocha will think that the test is async?

On 29 Jan 2017, at 05:54, Christopher Hiller notifications@github.com wrote:

@dasilvacontin oh, I remember. because you have to call it. you might not want to.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Also, how do you declare your intent of making an async test when using 't'?

In tape you always have to call 't.done' ('t.end' in their API), or set the expected amount of assertions ('t.plan').

Would it be possible to add a third argument to it() with options? That would not break API.

it ('accepts lambda', (done)=>{ doWork();  done(); }, {timeout:60000});

@boneskull

What if instead of putting the context first, it was an optional second?

Instead of this:

it('should do something', function (done) {
  this.timeout(9000);
  // stuff
  done();
});

it'd look like this:

it('should do something', (done, context) => {
  context.timeout(9000);
  done();
});

it('should do something', function (done, context) {
  // context is unused, but 'done' is now the second parameter
  this.timeout(9000);
  done();
});

We could provide an alternative bdd implementation that does this, however--it just wouldn't be the default.

That's about the most thorough explanation I have of "where this issue is at". 😄

or if context had to be some defined param

it('should do something', function (done, override) {
  // context is unused, but 'done' is now the second parameter
  override.timeout(9000);
  done();
});

But I'd take a non-default interface too :)

The downside to any solution that requires done is that you have to use done even if returning a promise would be simpler. Speaking for myself, I know I would rather type out function and return than .then(()=>{done()}, done)!

@Flamenco That's an interesting idea, although I might prefer to have the function last (yes, it's technically more "magical" that way but, let's face it, it's easy enough to check if the parameter is a function and it's intuitive enough to use and it's not like Mocha is being fed into some kind of other abstraction that such "magic" could break); such an options object could also be used to provide tags and/or pending-test reasons, both of which are requested features (finding them in the GitHub issues/PR list search box is left as an exercise to the reader) with which I'll admit to sympathizing (even if it's possible to work around their absence, there are advantages to the real thing over the workarounds).

@ScottFreeCode I do definitely agree about done I don't like to use it either, I was just commenting regarding the need to put the context first vs last and using the aforementioned example provided by boneskull.

I'd just love the option to pass in the context or to set some switch on mocha for es6 execution.

Meanwhile I'm just wrapping those few test descriptions which require timeout differences in a derpy-looking function() call.

I found a workaround for the use case where a promise is returned to mocha from an arrow function that needs a custom timeout, that I want to share in case others find it useful.

By adding the following when function defined below in a test declaration like so: it('does something', when(() => someFunctionReturningAPromise, customTimeout)) the mocha timeout can be set without giving up arrow functions.

Similarly, and because we're working only with promises, we can retake the first parameter to a test and pass in the context instead of the done callback: it('can access the mocha test context', when(testContext => someFunctionThatNeedsContext(testContext))

const when = (lambda, timeout) =>
  function() { // return a plain function for mocha to bind this to
    this.timeout(timeout || this.timeout() || 1000)
    return lambda(this)
  }

Some test cases to illustrate:

const delay = timeout =>
  new Promise((resolve, reject) => setTimeout(resolve, timeout))

const deject = timeout => // similar to above, but a delayed reject
  new Promise((resolve, reject) => setTimeout(reject, timeout))

describe('mocha testing', () => {
  context('with only arrow functions', () => {
    context('tests that do not time out', () => {
      it('passes fast', when(() => delay(10), 100))
      it('does not usually time out', when(() => delay(2000), 2010))
    })
    context('tests that will time out', () => { // these should fail if the 'when' function works properly
      it('times out fast', when(() => delay(1000), 10)) // will fail in 10ms
      it('times out', when(() => delay(1000), 1000)) // will fail in about 1000ms
    })
    context('tests that will reject', () => { // this shows the when function works as expected when a test rejects
      it('fails fast', when(() => deject(10), 100))
    })
  })
})

@astitt-ripple yep, or you simply write function () {}... Wtf?

Ok luca, ill bite. :-)

The difference with an arrow function, is the return can be skipped. In an
es6 type setup, this can already be a common pattern for promise 'then'
chains.

With a function block, as you suggest, and as far as i know, the return for
the promise must be explicit. Minimally for a promise based test function
{... } is wrong, a test must always return its promise, so the minimal
valid trivialization is actually: function { return ... }. Otherwise the
test returns undefined to mocha and not the dispatched promise... and the
test author has a bad time.

If most code in a codebase is already arrow functions from promise.then
and/or a functional programming style, adding function return can look
inconsistent. The suggested 'when' form is available instead for those who
prefer arrows and a more functional style than traditional function
callback or function return styles. Its more terse, and fits with the
decribe context it dsl we all agree we like writing tests in, taking into
account the promise async programming abstraction javascript handles so
well. Also its shorter than function+return, even without our pal curly:
when(() => ...).

Maybe thats not the preferred style of this project, i understand that, and
im not proposing it as a change to the project. Maybe its even
reprehensible as your wtf implies. Thats fine. Mocha has to work with
pre-fp friendly js. Backwards compatibility is a first class concern. That
also makes sense.

This is a long and deadlocked thread, and this is one way out. One nice
thing about javascript is there doesnt have to be one way or one style to
get things done. We dont have to agree on style at all. Functionally
speaking, my previous post gives people a way to use arrows and promises
consistently and with the test dsl, without giving up access to the mocha
context, in a clean and functional programming friendly way that had not
been previously suggested.

Thanks.

If most code in a codebase is already ... functional programming style...

...then using this.mutatingMethod(currentConfiguration) for setting behaviors, especially of a function (or rather subroutine) that is already being executed, is way more inconsistent than having to write return (which is just syntax), and inconsistent appearance would be making that reality more obvious rather than actually introducing the inconsistency.

(Don't get me wrong, I'm quite happy with the rise in popularity of functional programming ideas in JS; but the syntax of function/return vs => is not actually essential to functional programming, just a matter of what looks cleaner in that paradigm, whereas other concepts like purity and declarative vs. imperative are actually essential. It'd be neat to have a test runner that was, instead, more functional in its behavior/semantics, at which point switching to arrow functions would probably be trivial...)

I agree with you that this.timeout is mutational and breaks from the functional programming paradigm. Of course its totally inconsistent. At present, is there any other way to declare a custom timeout per test than this.timeout?

In the current implementation of mocha, it seems necessary to escape back to the imperative/mutational paradigm, or give up setting per test timeouts. One or the other.

In the above when abstraction, a timeout is the second parameter to when, allowing a functional style to remain at the test's level. It hides this inevitable escape from FP mode back to imperative programming, but does it in one place. Also, it gives arrow functions access to the mocha context, which isn't otherwise possible without breaking the test function parameter convention. So it potentially solves a few issues for some of this project's users (judging by this issue's history) in the interim until someone explores your test-runner idea.

Also please don't get me wrong either. I don't think functional programming will ever or should ever completely replace the turing machine derived imperative/mutational programming. For example in pretty much every case, in a JS runtime the code, functional or not, is ultimately interpreted by a program written in that more traditional imperative style (probably c++, but not necessarily), running on an operating system also written around mutational and imperative ideas (probably C). Memory is a fixed resource, immutable data structures are a lie the runtime tells us. That fundamentally imperative model is the default in computing, and is here to stay. But that doesn't mean functional programming cant co-exist on top of it. And if so, its inevitable that FP code has to drop down to the underlying model from time to time. I don't think that should mean we throw up our hands and say its all syntax, and lets just use function/return.

Actually we can do functional programming in C given a certain tolerance for detail, just as it is true that you can do functional programming with function/return instead of => functions. Just don't forget to return your promise. FP in C takes a small amount more typing, which after all, is just mere syntax.../s

At the end of the day, arrow functions get us incrementally closer to a workable and practical way to work in the lambda calculus model, in a popular language. Removing those extra characters makes a small but important difference. There are still many practical limitations, but many of these are solvable, the subject at hand is one of them.

Anyways. I'll use my suggested helper function, and others are free to use it too now. I look forward to your test-runner solution, but in the meantime, I don't know if its going to be particularly productive to continue trying to convince one-another of our own opinions on what syntax is important or not, as though there is one way. I like arrows, and you like functions. I haven't seen a cogent argument that changes my view. I'm open to one, but it had better be more thought out than knee-jerks like: "just use function, wtf" or "you can still do fp with a more verbose _syntax_".

Solve the problem another way, and then nobody needs to use when. Nuff said. :-)

I don't think that should mean we throw up our hands and say its all syntax, and lets just use function/return.

I like arrows, and you like functions.

...it had better be more thought out than knee-jerks like: ... "you can still do fp with a more verbose syntax".

That's pretty much the opposite of what I said, though -- I was going for the fact that arrow functions that still use this wouldn't be FP in the first place, they'd be OO with arrow functions (the inverse of FP with traditional JS functions). In other words, far from it being just a different syntax, the real problem is that there's a deeper paradigm incompatibility than just the syntax incompatibility (as Mocha is currently designed anyway).

I'm fairly sure it's possible to build an alternative interface on top of Mocha to replace this altogether with parameters. I just want to make it clear that if you want to go FP in writing tests you're going to have to do more than just come up with a way to pass Mocha's this to arrow functions. I'm very much for rising to that sort of challenge, however. ;^)

(There are also several other behaviors of Mocha that are stateful, global, or -- worse -- both, but I don't have time at the moment to come up with a brief way to list them. If you've ever seen the issues surrounding running Mocha more than once, that's an example of them, though.)

At present, is there any other way to declare a custom timeout per test than this.timeout?

Unfortunately, I'm fairly sure there isn't; off the top of my head the suggestion to accept an additional parameter to it that would be a key-value map (as a JS object) of configuration settings sounds like a decent future solution in Mocha, if anyone wants to try implementing it.

At present, is there any other way to declare a custom timeout per test than this.timeout?

Unfortunately, I'm fairly sure there isn't;

Thank you for confirming this detail. This solidifies the point I was making.

off the top of my head the suggestion to accept an additional parameter to it that would be a key-value map (as a JS object) of configuration settings sounds like a decent future solution in Mocha, if anyone wants to try implementing it.

+1 for a more general solution.

From what I can tell though, it seems workable to pass a single parameter still. Combine this with the done callback (so this becomes a function). Then have mocha run each test wrapped with a promise (well, two actually, one for handling the timeout, and one for actually running the test), regardless of the parameter count (departure from how it works today). It could then check that the result of the function was a promise or not. If not, call done after the synchronous function returns to finalize the test. If the result of the function is instead a promise, then wait for it to resolve (or reject). If the timeout occurs, stop the test (same as before). In the case where a test manages to call done and also return a promise. Either done is called before resolution, in which case mocha should wait for the promise and then fail the test for having an ambiguous completion sequence. Or done is called sometime after resolution, in which case somehow the test must be retroactively failed -- or the issue signaled some other reasonable way. Sorry thats a lot of broad strokes, but thats my outsider's understanding of what mocha is trying to do and the quirks its running into. What other considerations might prevent this from being a workable solution?

if you want to go FP in writing tests you're going to have to do more than just come up with a way to pass Mocha's this to arrow functions

agreed. there is a definite change in going to a different computational model, and in addition javascript is a complex ecosystem with much to consider. In my specific use case, however setting the timeout from time to time (such as to be more accurate based on some computation instead of a fixed default value), is the only tangible issue I've encountered writing FP tests with Mocha (so far at least). Which is great. :+1:

That said, I'd like to know what else you see as impending obstacles that specifically have to do with Mocha (as opposed to what writing tests in FP might mean in general).

That's pretty much the opposite of what I said, though

I am sorry if I mischaracterized or misunderstood. For a lot of what I wrote, I'm not sure I was getting across as intended either, based on the replies. Which is unfortunate, since I think if we got down to it, we would probably come to pretty close agreement on what FP _should_ look like in _theory_. Here it seems however, we disagree as to what a workable reduction to _practice_ might look like in the currently available releases of Mocha today, at least for some users/use-cases. So I'm not quite sure exactly what the major issue is with the proposed add-on function I proposed, from your side.

(Quoted and replied in order, but arguably the more important stuff is later rather than earlier.)

From what I can tell though, it seems workable to pass a single parameter still. Combine this with the done callback (so this becomes a function). Then... What other considerations might prevent this from being a workable solution?

If we break backwards-compatibility, there are way simpler designs we could switch to.

If we keep backwards compatibility, both of these tests need to pass and not time out:

it("runs immediately", () => {
  // call functions and assert whatever
})
it("runs asynchronously", doneWithSomeOtherName => {
  setTimeout(() => {
    // call functions and assert whatever
    doneWithSomeOtherName()
  }, 100)
})

You're welcome to try to come up with some example code to prove otherwise (although I'd suggest focusing on the suggestion at the end of this comment instead), but I'm fairly sure no design will be able to do that and also make this test pass and not time out:

it("looks just like an asynchronous test with a different name for `done`, but never tells Mocha it's done", context => {
  context.configureByMutation("some value")
  // call functions and assert whatever
})

But also, notice the mutation there. More on this below.

In my specific use case, however setting the timeout from time to time (such as to be more accurate based on some computation instead of a fixed default value), is the only tangible issue I've encountered writing FP tests with Mocha (so far at least). Which is great.

:+1:!

That said, I'd like to know what else you see as impending obstacles that specifically have to do with Mocha (as opposed to what writing tests in FP might mean in general).

I think I may not have been communicating this quite focus...edly, so let me see if I can boil it down a bit further. (Also sorry if any of this has come off as antagonistic; it certainly isn't intended to be, although I'll admit to trying to change mindsets here.) Mocha's codebase is very much of the class hierarchies and getters and setters style of "object orientation" (and there are multiple issues or potential issues Mocha has that I believe come down to its mutable state), but that doesn't generally affect your test code if all you're doing is writing tests and letting Mocha run them. You can do weird things with Mocha's imperative mutating configuration:

it("imperatively sets the timeout multiple times", function(done) {
  this.timeout(5000)
  var context = this
  setTimeout(function() {
    context.timeout(1000)
    setTimeout(done, 500)
  }, 4000)
})

...but you don't have to. As with so many elements of programming functionally in non-functional languages: just don't abuse the imperative stuff.

(There's also an argument to be made that exceptions are impure, but I'm not yet convinced that's true of exceptions that are thrown based on the input -- which could just be considered another form of output. So some would say that using assertions that throw is not functional, but I'm not going to tackle that at this point.)

(Important part here:) What I'm trying to get at is, we're looking at potentially either adding complication to an already complex codebase, or else making a backwards-incompatible change. We need justification for either of those things. If the justification is "make tests more functional", that's good (in my book anyway). A design that makes tests more functional might be worth the trouble (depending on how much trouble it is). But if by "make tests more functional" you mean "make arrow functions mutate things", i.e. "make arrow functions less functional", that weakens the case a lot (if it isn't just self-contradictory). More completely: I don't think that making tests look more functional (as clean as arrow functions do look!) while retaining the one bit of mutation involved, however small that bit was to begin with, is nearly as compelling a justification as actually getting rid of that bit of mutation would be -- at least if the point is to make tests more functional.

I probably shouldn't even have got so far off on this tangent though; see below concerning solutions. 😸

So I'm not quite sure exactly what the major issue is with the proposed add-on function I proposed, from your side.

(Also important part here:) Well I like the bit where it takes the timeout as a parameter instead of a method call, actually! If you can come up with a way to generalize that to the rest of Mocha's configuration methods (there are a lot of them -- and some apply to synchronous tests if I recall correct, hence why we can't just add the same methods as properties on done and let people write asynchronous tests that can call configuration through done, but I digress), then I'd definitely want to take a look at it. At the very least we may want to make it a recommendation, and we might even be able to adopt the implementation into it when passed a third parameter (or something like that, maybe it.configured or it(...).configured(...) if we don't want more number-of-parameters shenanigans...) -- which I think would be a backwards-compatible solution that tackles the underlying mutation/imperative matter and gets arrow function support "the right way" (what I'm arguing is such anyway): because it fits the new behavior. I guess what I should have said, rather than going after this in the workaround, is: let's expand the parameter part of it!

I swear I read somewhere you could do something like this:

describe('a slow thing', () => {
 // test code...
}).timeout(5000);

which doesn't alter the parameter contract to the provided function. Now I can't find any reference to any such thing so maybe I just imagined it.

@thom-nic this works! i guess it makes sense since all of mocha's functions returns its context

return this;

It works with me when replacing the arrow function form with the normal function

function() { ..... }

Hi Folks. I apologize for going dark after sparking the discussion back in august, i've been quite busy and actually have mostly completed/moved-on from that work.

I appreciate the detailed response about the different use cases and how its hard to dovetail them together. That was the most concise showing of the different setups mocha has to support that I've read. So thank you for your time on that one.

Looking back, its clear that I must have over-emphasized getting access to mocha context (this), when that aspect was really more of a convenient after-thought. I didn't realize how easily it would draw attention away from what I was actually trying to do: which was having some fun by adding a temporal'ish extension (when) to the test dsl for streamlining one-off timeout adjustments (plus eliminating a common error for a particular style of tests, which I'll explain below). Returning this was just another fun thing I thought of adding, the main idea (hence the name when) was for handling cases that needed different timeouts than normal.

Obviously, if I wanted to access the bound context I could simply use function directly as many have suggested, rather than hoisting it out with a wrapper. Thats not the issue. 😄 It isn't lost on me how that might seem strange on the face of it. I'm hoping maybe it will round out the picture if I show how I was setting up some of the tests which led me down this path to begin with. To be clear, I'm not trying to sell any particular style here, use what works for you. This is what worked for me.

Ok
First off, start with the assumption that we're testing some setup that basically does one thing, but will do it for a wide range of inputs, and so we must test this thing out in a bunch of scenarios to ensure the outputs are correct. However, since the relevant application code "does one thing", the underlying test procedure is pretty much always the same. I also don't want to duplicate/mutate the test body needlessly, since that slows down how quickly I can add more test cases for new inputs and eventually the maintenance would become unreasonable.

So instead we write a function thats general enough to start the application code up with any potentially supported inputs, perform the test action, and then assert the results... Add that in my case I was working with the Promise abstraction (for reasons that i'll leave out), so this generalized test procedure function naturally has to return that promise.then chain. Bread and butter es6 kind of stuff, so far so good.

Now comes the test scenarios, since we packed everything into our test-procedure function, the test cases are effectively defining the inputs and invoking the function.

So perhaps I write a bunch of tests like this, and everything _seems_ to be working:

it('does something', function() {
  testProcedureFunction('something','1')
})

If you're following along closely, you will have probably noticed already that this example has a bug. It is missing its return, and since testProcedureFunction is built on promises (pun intended), its always going to pass no matter whether the assertions at the end passes or fails. This is a bug, and it can be an extremely subtle one to track down sometimes. To illustrate, depending on how we wrote testProcedureFunction and how the application is written, lets say there is some synchronous code at the start, and that blows up instead of the end-of-test assertions, the testcase might even fail -- leading us to think everything is fine.

The test should of course really look like this with a return:

it('does something', function() {
  return testProcedureFunction('something','1')
})

Now I know this test is going to be one line in most cases. Actually, every case will be one line, except for when the inputs are such that a larger timeout is required. Now among the differences between classical js functions and arrows, there is a particular aspect of arrow functions that is useful here: a single statement arrow function has an implied return when braces are omitted. If instead of writing a function {...}, a test uses the => ..., then I can easily scan those cases for the arrow and the lack of curly braces, and quickly infer that they cannot have this missing return issue, and it will take some extra steps (adding the braces back) for someone to mess that up.

Like so:

it('does something', () => testProcedureFunction('something','1'))

Now what if one of these cases takes longer than the others! We can of course set the timeout like this:

it('does something slow', function() {
  this.timeout(10000)
  return testProcedureFunction('somethingSlow','2')
})

Or maybe someone will make a mistake and do this first (which doesn't work of course):

it('does something slow', () => {
  this.timeout(10000)
  return testProcedureFunction('somethingSlow','2')
})

But now we're back where we started, the codebase has a pattern ripe for repeating, which is susceptible to the missing return bug (either by future me, or the next person to add a feature -- the point is, its an easy mistake to make, it may go unnoticed, and it can be hard to track down). The when function solves this, and lets us use arrows consistently again:

it('does something slow', when(() => testProcedureFunction('somethingSlow','2'), 10000))

(note, i wasn't able to get the .timeout(5000) dot-chaining suggestion above to work, may have been due to the version of mocha i needed to use, I don't remember anymore, will give that a try!)
(note2, notice that the use of when isn't using the this parameter hoisting trick -- it really was just an after-thought).

Maybe there are linters that can flag missing returns-for-promise bugs (or probably more realistically, enforcing a return statement with a rhs for every function). However that wasn't an option at the time, plus I think the arrow syntax comes out shorter and I find it (subjectively/personally) easier to read and work with, which tipped the scales for me away from function.

So there you have it.

I don't know if I'll have time to respond again anytime soon, so I hope that was at least informative and clear, and maybe even puts some of the controversy surrounding the whole "access to mocha-context from arrows" stuff to bed.

Lastly, since I found function vs => confusing for a long time, I'll drop this link in case its not clear to anyone casually reading why arrows can't access this. It was the clearest explanation of functions vs arrows that I've found, and was what helped me finally understand the differences well enough to use them with full confidence.

https://hacks.mozilla.org/2015/06/es6-in-depth-arrow-functions/

@thom-nic It works on it, but not on describe.

describe('my test suite', () => {

  it('test case 1', () => {
    // ...
  }).timeout('10s');  // Works on `it`. This test case doesn't timeout

  it('test case 2', () => {
    // ...
  });  // This test case timeouts.

}).timeout('10s');  // Doesn't work on `describe`. Tests are already created when runs to here.

@thom-nic , you may use the normal function form

describe('my test suite', function() {
this.timeout(n);

...
}

Anyone complaining about this doesn't understand arrow functions.

Arrow functions are NOT a new fancy ES6 thing is supposed to replace the classic function () {}. The only purpose of arrow functions is that it inherits this from it's parent, where the classic function () has it's own this.

Yes, even when using full ES6 syntax, you should still be using function () if you want to use this in the correct context of your function. You should be using both function () and () => in your ES6 application depending on what you are trying to do.

this.timeout() doesn't work with it('....', () => { ... }) because the callback is inheriting this from the parent describe() function, in which this.timeout() doesn't make sense on that level.

Don't lambda functions also allow you to automatically send a single argument to the function without declaring it in the call?

(param)=>aFunction
...then(aFunction)

function(){} can be bound to 'this' but ()=> is 'locked in'

Arrow functions should replace the traditional function when the receiver expects a pre-determined 'this' in the same context that it is called from, (and also benefit from typing less code).

I would go so far as to say never use function() unless you want 'this' to be something other than what 'this' is when invoking it.

@Flamenco...

Don't lambda functions also allow you to automatically send a single argument to the function without declaring it in the call?

I'm not sure I understand _exactly_ how you're putting that.
As far as "sending arguments to the function", fat arrows work just like regular functions with a single exception: if you have exactly 1 argument, then you can leave off the parenthesis.

() => console.log("hi"); //zero arguments requires empty parenthesis
a => console.log(a); //you can optionally leave the parenthesis off for 1 argument
(a,b) => console.log(`${a} ${b}`); //2..n arguments requires parenthesis

What you may have been getting at is that fat arrows allow you to _return_ a value by omitting the curly braces and the return keyword as long as your function is a single expression.
So if you had...

setTimeout(function(a,b) { doSomething(); return calculateSomething(a,b); }, 5000);

...and you wanted to convert that into a fat arrow function, you would not be able to shake the curly braces and the return keyword because the function body has multiple statements. You'd do it like this...

setTimeout((a,b) => { doSomething(); return calculateSomething(a,b); }, 5000);

If, rather you started with...

setTimeout(function(a,b) { return calculateSomething(a,b); }, 5000);

...then you're dealing with a function that so simple that it just returns a single expression and you could use...

setTimeout((a,b) => calculateSomething(a,b), 5000);

That got a lot easier to read!
I wrote a bit more about this at codefoster.com/levelup-arrays.

There are many different coding styles in JavaScript -- from OOP to FP, from strict type-safety to mixin/duck-typing. In addition, there are advanced patterns in each of those styles (i.e. dependency injection in OOP camp, currying/monad in the FP camp).

If your coding style is closer to FP where this is not used and arrow functions are used to reduce boilerplate, having to preserve this is an extra overhead for any advanced testing (e.g. parameterized testing, creating DSL).

Any experienced developer can just pre-wrap the testing framework to suit their coding style, but that means the framework is less "out-of-the-box". That translates to extra work for upgrading, adopting plugins, and onboarding new engineers.

I like the idea of an alternative bdd interface which doesn’t use this and instead passes what would normally be the context object as a parameter to describe, it and hooks.

But it’s not so straightforward to implement, IIRC. Would be cool to see an attempt though.

I know this is getting into serious side-effects land, but couldn't you deal with the done-or-context parameter something like this?

it("runs immediately", () => {
  // call functions and assert whatever
})

it("runs asynchronously", doneOrContext => {
  setTimeout(() => {
    // call functions and assert whatever
    doneOrContext();
  }, 100)
})



md5-b1fe6f00c87a2916712cf6a4df16e142



it("runs immediately using the parameter as a context", doneOrContext => {
  doneOrContext.configureByMutation("some value");
  // As well as changing config, also flags to Mocha that this test is treating the
  // parameter as a context object and is therefore not async.
  // Call functions and assert whatever
})



md5-b1fe6f00c87a2916712cf6a4df16e142



it("runs asynchronously using the parameter as a context", doneOrContext => {
  doneOrContext.configureByMutation("some value");
  doneOrContext.setAsync(); // Flags to Mocha that even though the parameter has been used as
  // a context object, the test is in fact asynchronous.
  setTimeout(() => {
    // call functions and assert whatever
    doneOrContext();
    // or doneOrContext.done()
  }, 100)
})

i used the below script but i got the same Timeout exceed error.

Myscript :

describe("getBillingDetail", async function (){
this.timeout(55000);
it.only("check given valid Jobname",async function (done){
this.timeout(55000);
var result = await url.getBillingDetail('12254785565647858');
console.log(result);
assert.equal(result,true);
});
});

Error: Timeout of 55000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.

Don't pass a done callback to an async function

I've created a prototype solution that's backwards compatible. For now it's a separate module, but functionality could easily be merged into mocha proper.

https://github.com/papercuptech/mocha-lambda

quick way

require('mocha-lambda')
// now a global '_tst' can be used where 'this' was before

describe('suite', () => {
  beforeEach(() => {
    _tst.answer = 42
  })

  it('provides "this" as "_tst"', function() {
    assert(this === _tst)
  })

  it('works', () => {
    assert(_tst.answer === 42)
    _tst.skip()
  })
})

for explicit naming (and works with TypeScript)

// if you were previously explicitly importing api (describe, it, etc.) from 'mocha',
// you will have to change to importing from 'mocha-lambda', until (or if) this
// gets merged into mocha proper
import ctx, {describe as d, it as i} from 'mocha-lambda'

d('suite', () => {
  // ctx() is a function that returns "this" as appropriate
  i('works using ctx()', () => {
    ctx().skip()
  })
})

import {Context} from 'mocha'
// ctx() can also rename global
ctx('t')
declare var t: Context
d('suite', () => {
  // ctx() is a function that returns "this" as appropriate
  i('works using renamed global', () => {
    t.skip()
  })
})

@papercuptech The link is 404 not found.

Woops.. was private repo. now public

Can also npm i mocha-lambda

@aleung @linesh-simplicity, this is superseded by #3485

Thanks.

Why so many "magic" that, at the end, produces problems? Why not this?:

var mocha = require('mocha');

mocha.describe('foo', (suite) => {
  suite.timeout(100);

  suite.it('must love bar', () => ... );  
});

No globals, no problematic magic... but just JavaScript.

see @thom-nic answer, clean and did the trick

I swear I read somewhere you could do something like this:

describe('a slow thing', () => {
 // test code...
}).timeout(5000);

which doesn't alter the parameter contract to the provided function. Now I can't find any reference to any such thing so maybe I just imagined it.

@thom-nic solution worked for me, thanks!