mocha: Async test fails with timeout instead of assertion error

I ran into a similar problem, and eventually realized you shouldn’t use done when testing asynchronous functions with promises, instead, just return the promise. So you should be able to do this without the timeout, e.g.:

it('returns the correct value', function() {
    var returnValue = 5;

    return aPromise.then(function() {
        expect(returnValue).to.equal(42);
    });
});

@gurdiga it seems to me that your promise has its own error catching. Try to add a .catch(done) to your promise and I think it’ll work as intended.

I feel stupid.

I think I finally got it: when anything throws in any of the promise’s handler functions, be it the one passed to .then(), to .catch() or to .finally(), the error is handled by the promise library. This way, the test runner never sees the real error, the done() is never called (because something before it threw an assertion error), and so the time out error is all you get from the test runner.

To get out of the promise, I use setTimeout():

    it('returns the correct value', function(done) {
      var returnValue = 5;

      aPromise.then(function() {
        setTimeout(function() {
          expect(returnValue).to.equal(42);
          done();
        });
      });
    });

I found this is the only way to get proper error messages and test runner behavior.

With done passed to .catch() or .finally() the test is considered passed in any case, so if there are assertion errors, you’ll never see them.

Stop spelling the same thing in multiple closed issues. Don’t pass a done callback into async functions. Read the documentation on async tests

@stevenvachon: Forgive me in advance, but I don’t see an immediate issue with your example. The assertions made in your event listeners should be handled by Mocha via the uncaughtException mapping (unless the event emitter implementation is catching listener errors and emitting an error event or something, which then is still easy to solve).

Now if your implementation under the hood is using Promises, but emits events rather than exposes the Promise, your assertions will indeed be “eaten”. The way I get around this problem is to use unhandledRejection.

I usually put this in a setup script that is run before my tests:

process.on('unhandledRejection', function (reason)
{
    throw reason;
});

Note: This may need some extra elbow grease to work in browsers.

I hope to to see Mocha support this like it does uncaughtException as this is a common use case; just because I use Promises doesn’t mean I want to return them to the caller!

I think that this issue still exists. I’m getting a timeout issue that cannot be resolved by returning a promise because my module does not use promises.

it("works", function(done) {
    new Something()
    .on("eventA", function(result) {
        expect(result).to.be.true;
    })
    .on("eventB", function(result) {
        expect(result).to.be.false;
        done();
    });
});

• Wrapping the instance in a Promise seems excessive.
• Wrapping each assertion in a try/catch also seems excessive and, more importantly, results in Error: done() called multiple times.

Ideas: http://staxmanade.com/2015/11/testing-asyncronous-code-with-mochajs-and-es7-async-await/

@itumoraes that works, but you can do this instead:

describe('Clicking in any bad reputation tag', () => {
    it('open the bad reputation modal', () => {
      return nightmare
        .select('#per-page', '50')
        .waitForAjax()
        .click('[data-reputation="bad"]')
        .evaluate(function() {
          return document.querySelector('.vue-modal .ls-modal-title').innerText
        })
        .then(function(title) {
          title.should.equal('Sua segmentação teve uma avaliação ruim!')
        })
    })
  })

You don’t need to call done() if you return a promise. See my blog post Using Async/Await with Mocha, Express, and Mongoose

It looks like that your promise never resovled.

@gurdiga Thanks for the setTimeout() idea! I had a similar problem, but now I can get proper error messages atleast!

1. Yes, and I use an "end"/"drain" event to check if booleans in the other events were set.
2. The timeout happens. I’m trying to find a lean and clean alternative.